From daemon@optimus.ietf.org Thu Aug 1 03:18:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02875 for ; Thu, 1 Aug 2002 03:18:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17077 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 03:20:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15054; Thu, 1 Aug 2002 02:46:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15021 for ; Thu, 1 Aug 2002 02:46:32 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08863 for ; Thu, 1 Aug 2002 02:45:21 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g716eDm17421; Thu, 1 Aug 2002 12:10:15 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C08.00251983 ; Thu, 1 Aug 2002 12:15:13 +0530 X-Lotus-FromDomain: HSSBLR To: Tom_Gray@Mitel.COM cc: amish.chana@orange.co.uk, sip@ietf.org Message-ID: <65256C08.002518D7.00@sampark.hss.hns.com> Date: Thu, 1 Aug 2002 12:15:08 +0530 Subject: Re: [Sip] SIP Congestion Control Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Taking an analogy from the ACC procedure defined for ISUP, as well as Tom's comment below, it is the network management entity at the servers that will have to detect, indicate(to other/adjacent servers) and act when such 'overload condition' occurs on the SIP servers. The support that would be required by the NM entities would be an ability to communicate the overload condition(levels or whatever) to the servers it is connected to. The NM entities residing on the adjacent servers can then take suitable actions. So, as far as SIP is concerned it should be sufficient to have a mechanism by which NM entities can exchange overload indications over SIP. The INFO method may be used for this purpose to share such application level information. This may not be exactly similar to ACC procedure in ISUP where the REL message is used to convey the overload congestion levels, but the purpose would be served equally well. regards Harsh Tom_Gray@Mitel.COM on 07/31/2002 10:35:15 PM To: amish.chana@orange.co.uk cc: sip@ietf.org Subject: Re: [Sip] SIP Congestion Control Wouldn't this sort of load shedding or load balancing issue be best dealt with at the application and not the protocol layer. amish.chana@orange.co.uk@ietf.org on 07/31/2002 11:34:51 AM Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: [Sip] SIP Congestion Control Hi, Does SIP support congestion/flow control methods during application level processing overload? (e.g. something equivalent to ISUP's ACC) This is typically for scenarios where there could be a burst of calls (possibly due to some media stimulated event) and hence a burst of SIP messages. The target of these messages could either be a proxy server, voicemail server or some other media server. I am assuming there are sufficient resources in the IP network and no packets will be dropped. From going through RFC3261 SIP seems to rely on the congestion controls of the transport protocols. draft-willis-sip-congestsafe-00.txt also seems to address the case where a transport network protocols like TCP and SCTP provide feedback control. Thanks, Amish *************************************************************************** **** Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *************************************************************************** **** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 daemon@optimus.ietf.org Thu Aug 1 05:11:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12616 for ; Thu, 1 Aug 2002 05:11:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04640 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 05:13:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21219; Thu, 1 Aug 2002 04:43:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21190 for ; Thu, 1 Aug 2002 04:43:13 -0400 (EDT) Received: from dumbledore.orange.co.uk (smtpout11.orange.co.uk [193.35.135.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10261 for ; Thu, 1 Aug 2002 04:42:04 -0400 (EDT) From: amish.chana@orange.co.uk Received: from bot.orange.co.uk (bot.orange.co.uk) by dumbledore.orange.co.uk (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Aug 2002 09:34:05 +0100 Received: from ruddick (notes-gw.orange.co.uk [172.16.133.18]) by bot.orange.co.uk with SMTP id g718b9E01879; Thu, 1 Aug 2002 09:37:09 +0100 (BST) X-Lotus-FromDomain: HTLUK To: "Naidu, Venkata" cc: sip@ietf.org Message-ID: <80256C08.002F93D8.00@ruddick> Date: Thu, 1 Aug 2002 09:40:41 +0100 Subject: RE: [Sip] SIP Congestion Control Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Venkata, See my responses below... "Naidu, Venkata" on 31/07/2002 17:27:49 To: Amish CHANA/EN/HTLUK@HTLUK sip@ietf.org cc: Subject: RE: [Sip] SIP Congestion Control Amish, -> I am assuming there are sufficient resources in the IP -> network and no packets will be dropped. Then where is the congestion in the network? [Amish] My question applies to the case where possibly a large number of SIP INVITEs are being sent to a proxy or media server. They are is overload since they are unable to process such a large number of requests simultaneously. This is analogous to the case in the PSTN where an exchange is unable to process a large number of calls. In the PSTN this is dealt with using the ISUP ACC to get the adjacent nodes to throttle back their traffic. To get back to your congestion. If by network we refer to the IP network between the UAs, proxies, media servers, etc. Then there is no congestion in the network. We have overloaded servers. -> From going through RFC3261 SIP seems to rely on the -> congestion controls of the -> transport protocols. -> draft-willis-sip-congestsafe-00.txt also seems to address -> the case where a -> transport network protocols like TCP and SCTP provide -> feedback control. I don't think congestion control, flow control methods are required in session/application level protocols when they depend on well tested, extensively reserached transport protocols (like TCP and respective extensions). [Amish] Yes. But how is application level processing overload addressed if the transport level is working perfectly - i.e. no packet loss, delays, etc.? -Amish. Looks like every higher layer protocols are trying to solve their own congetion/flow control. Yes! I agree that there must be some corner cases where you can optimize/improve protocols (like SIP, BGP etc) when there is much stress. But the problems you are trying to solve are very corner cases when you implement congestion/flow control in SIP, BGP etc I feel that this is duplicate work unless SIP is going achieve good preformance improvement with it's own congestion/flow control mechanisms when compared to best TCP extension(s). -- Venkata. ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 05:38:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14871 for ; Thu, 1 Aug 2002 05:38:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA16886 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 05:39:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02345; Thu, 1 Aug 2002 05:11:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02167 for ; Thu, 1 Aug 2002 05:11:03 -0400 (EDT) Received: from dumbledore.orange.co.uk (smtpout11.orange.co.uk [193.35.135.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12262 for ; Thu, 1 Aug 2002 05:09:53 -0400 (EDT) From: amish.chana@orange.co.uk Received: from bit.orange.co.uk (bit.orange.co.uk) by dumbledore.orange.co.uk (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Aug 2002 10:07:43 +0100 Received: from ruddick (notes-gw.orange.co.uk [172.16.133.18]) by bit.orange.co.uk with SMTP id g719AnH26071; Thu, 1 Aug 2002 10:10:49 +0100 (BST) X-Lotus-FromDomain: HTLUK To: hbhondwe@hss.hns.com cc: Tom_Gray@Mitel.COM, sip@ietf.org Message-ID: <80256C08.0032A785.00@ruddick> Date: Thu, 1 Aug 2002 10:14:18 +0100 Subject: Re: [Sip] SIP Congestion Control Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Harsh, See my response below..... hbhondwe@hss.hns.com on 01/08/2002 07:45:08 To: Tom_Gray@Mitel.COM cc: Amish CHANA/EN/HTLUK@HTLUK sip@ietf.org Subject: Re: [Sip] SIP Congestion Control Taking an analogy from the ACC procedure defined for ISUP, as well as Tom's comment below, it is the network management entity at the servers that will have to detect, indicate(to other/adjacent servers) and act when such 'overload condition' occurs on the SIP servers. [Amish] I agree. The support that would be required by the NM entities would be an ability to communicate the overload condition(levels or whatever) to the servers it is connected to. The NM entities residing on the adjacent servers can then take suitable actions. So, as far as SIP is concerned it should be sufficient to have a mechanism by which NM entities can exchange overload indications over SIP. The INFO method may be used for this purpose to share such application level information. This may not be exactly similar to ACC procedure in ISUP where the REL message is used to convey the overload congestion levels, but the purpose would be served equally well. [Amish] I received two off-line emails after this post suggesting the use of 503 Service Unavailable. IMO using 503 seems to be a better approach. I would say that a method of exchanging overload information (and possibly actions at the receiving end - if it is a proxy) needs to be clearly specified so that actions at the transmitting end are predictable. -Amish regards Harsh Tom_Gray@Mitel.COM on 07/31/2002 10:35:15 PM To: amish.chana@orange.co.uk cc: sip@ietf.org Subject: Re: [Sip] SIP Congestion Control Wouldn't this sort of load shedding or load balancing issue be best dealt with at the application and not the protocol layer. amish.chana@orange.co.uk@ietf.org on 07/31/2002 11:34:51 AM Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: [Sip] SIP Congestion Control Hi, Does SIP support congestion/flow control methods during application level processing overload? (e.g. something equivalent to ISUP's ACC) This is typically for scenarios where there could be a burst of calls (possibly due to some media stimulated event) and hence a burst of SIP messages. The target of these messages could either be a proxy server, voicemail server or some other media server. I am assuming there are sufficient resources in the IP network and no packets will be dropped. From going through RFC3261 SIP seems to rely on the congestion controls of the transport protocols. draft-willis-sip-congestsafe-00.txt also seems to address the case where a transport network protocols like TCP and SCTP provide feedback control. Thanks, Amish *************************************************************************** **** Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *************************************************************************** **** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 09:16:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29547 for ; Thu, 1 Aug 2002 09:16:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25717 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 09:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24260; Thu, 1 Aug 2002 08:48:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24232 for ; Thu, 1 Aug 2002 08:48:07 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28218 for ; Thu, 1 Aug 2002 08:46:55 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g71Cxtf00292 for ; Thu, 1 Aug 2002 15:59:55 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 1 Aug 2002 15:48:05 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 1 Aug 2002 15:48:04 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id PAA22837 for ; Thu, 1 Aug 2002 15:48:04 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id g71DcsM04400; Thu, 1 Aug 2002 16:38:54 +0300 To: sip@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB7C2041B@esebe019.NOE.Nokia.com> <1027935307.3d450c4b68d6a@imp.free.fr> <1027952996.6720.9.camel@dhcp112.dfw.dynamicsoft.com> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <1027952996.6720.9.camel@dhcp112.dfw.dynamicsoft.com> Date: 01 Aug 2002 16:38:53 +0300 Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 01 Aug 2002 12:48:04.0929 (UTC) FILETIME=[ADB99B10:01C23959] Subject: [Sip] REFER and dialogs terminated by BYE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, Let's say a REFER is used to transfer an existing call. REFER is sent using the existing dialog. Now, what should happen to the dialog and the subscription(s) when either end uses BYE to terminate the original call before the subscription(s) created by REFER have terminated? BR, Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 11:07:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03338 for ; Thu, 1 Aug 2002 11:07:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01625 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 11:08:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29934; Thu, 1 Aug 2002 10:39:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29876 for ; Thu, 1 Aug 2002 10:39:19 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02302 for ; Thu, 1 Aug 2002 10:38:10 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71EcsD29455; Thu, 1 Aug 2002 09:38:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 09:38:40 -0500 Message-ID: From: "Sriram Parameswar" To: "'Pekka Pessi'" , sip@ietf.org Subject: RE: [Sip] REFER and dialogs terminated by BYE Date: Thu, 1 Aug 2002 09:38:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23969.202489D0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23969.202489D0 Content-Type: text/plain; charset="iso-8859-1" Good question - my initial reaction would be that the receipt of the BYE would terminate the Implicit Subscription just as a 481 may be used to terminate subscriptions. Further - no NOTIFYs will be sent on the terminated subscription. Regards, Sriram -----Original Message----- From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] Sent: Thursday, August 01, 2002 8:39 AM To: sip@ietf.org Subject: [Sip] REFER and dialogs terminated by BYE Hello, Let's say a REFER is used to transfer an existing call. REFER is sent using the existing dialog. Now, what should happen to the dialog and the subscription(s) when either end uses BYE to terminate the original call before the subscription(s) created by REFER have terminated? BR, Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C23969.202489D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] REFER and dialogs terminated by BYE

Good question - my initial reaction would be that the = receipt of the BYE would terminate the Implicit Subscription just as a = 481 may be used to terminate subscriptions. Further - no NOTIFYs will = be sent on the terminated subscription.

Regards,

Sriram

-----Original Message-----
From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]<= /FONT>
Sent: Thursday, August 01, 2002 8:39 AM
To: sip@ietf.org
Subject: [Sip] REFER and dialogs terminated by = BYE


        Hello,

        Let's say = a REFER is used to transfer an existing call. REFER is
        sent = using the existing dialog. Now, what should happen to the
        dialog = and the subscription(s) when either end uses BYE to
        terminate = the original call before the subscription(s) created
        by REFER = have terminated?
       =20
        BR,

        =         =         =         =         Pekka

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C23969.202489D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 11:07:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03354 for ; Thu, 1 Aug 2002 11:07:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01637 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 11:08:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00058; Thu, 1 Aug 2002 10:41:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00015 for ; Thu, 1 Aug 2002 10:41:32 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02336 for ; Thu, 1 Aug 2002 10:40:23 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g71EeeL1022367 for ; Thu, 1 Aug 2002 10:40:41 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 09:41:02 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A349@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Subject: RE: [Sip] REFER and dialogs terminated by BYE Date: Thu, 1 Aug 2002 09:41:00 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org RFC 3261 leaves this open ("The mechanism for terminating confirmed dialogs is method specific.") There is some guidance about how this applies to dialogs associtated with subscriptions in section 3.3.4 of RFC 3265. In partcular, the following (non-normative) explanation from that section is of interest: "...[A] dialog created with an INVITE does not necessarily terminate upon receipt of a BYE." For the particular case you describe, then, the answer is that the dialog and subscription are not destroyed until a NOTIFY with a "Subscription-State" of "terminated" is sent. /a > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Thursday, August 01, 2002 8:39 > To: sip@ietf.org > Subject: [Sip] REFER and dialogs terminated by BYE > > > Hello, > > Let's say a REFER is used to transfer an existing call. REFER is > sent using the existing dialog. Now, what should happen to the > dialog and the subscription(s) when either end uses BYE to > terminate the original call before the subscription(s) created > by REFER have terminated? > > BR, > > Pekka > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Thu Aug 1 11:36:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03973 for ; Thu, 1 Aug 2002 11:36:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03613 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 11:37:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01485; Thu, 1 Aug 2002 11:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01454 for ; Thu, 1 Aug 2002 11:06:04 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (h2s128a211n47.user.nortelnetworks.com [47.211.128.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03298 for ; Thu, 1 Aug 2002 11:04:54 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71F5MZ25440; Thu, 1 Aug 2002 16:05:22 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 16:05:23 +0100 Message-ID: From: "Mark Watson" To: "'amish.chana@orange.co.uk'" , "Naidu, Venkata" Cc: sip@ietf.org Subject: RE: [Sip] SIP Congestion Control Date: Thu, 1 Aug 2002 16:05:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2396C.D966E2C8" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2396C.D966E2C8 Content-Type: text/plain; charset="iso-8859-1" > [Amish] My question applies to the case where possibly a > large number of SIP > INVITEs are being sent to a proxy or media server. They are > is overload since > they are unable to process such a large number of requests > simultaneously. This > is analogous to the case in the PSTN where an exchange is > unable to process a > large number of calls. In the PSTN this is dealt with using > the ISUP ACC to get > the adjacent nodes to throttle back their traffic. > I think there is an important difference between ISUP ACC and SIP in this respect. The ISUP ACC mechanism is based on a model of a non-distributed system in which the exchange attempts to provide a valid response to every ISUP IAM coming in. Starting from a point at which the exchange can fully process all messages sucessfully, as the offered load increases, the exchange starts to reject some IAMs with release due to overload. As the offered load increases further, the processing time used to send these rejections increases and starts to reduce the processsing time available for completing sucessful calls. Increasing the offered load further, you reach a point where all the processing time is used to reject IAMs, and there is no sucessful traffic. The solution is to request adjacent nodes to reduce the offered load, hopefully stabilising it at the point at which all messages are sucessfully processed. In my view, this is not a very good design, because the exchange is relying on other elements in order to maintain its own integrity. If those other elements do not behave as expected, then the capacity of the congested element drops. As I understand it, in SIP, messages can just be dropped if they cannot be processed. There is potentially no processor load associated with dropping the packet. This causes the sender to back-off on retransmits (the sender doesn't see any difference between network congestion and nodal overload). I know this is a bit of a simplistic view, but I'm sure someone will correct me if it's completely wrong :-) ...Mark ------_=_NextPart_001_01C2396C.D966E2C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] SIP Congestion Control

> [Amish] My question applies to the case where = possibly a
> large number of SIP
> INVITEs are being sent to a proxy or media = server. They are
> is overload since
> they are unable to process such a large number = of requests
> simultaneously. This
> is analogous to the case in the PSTN where an = exchange is
> unable to process a
> large number of calls. In the PSTN this is = dealt with using
> the ISUP ACC to get
> the adjacent nodes to throttle back their = traffic.
>

I think there is an important difference between ISUP = ACC and SIP in this respect. The ISUP ACC mechanism is based on a model = of a non-distributed system in which the exchange attempts to provide a = valid response to every ISUP IAM coming in. Starting from a point at = which the exchange can fully process all messages sucessfully, as the = offered load increases, the exchange starts to reject some IAMs with = release due to overload. As the offered load increases further, the = processing time used to send these rejections increases and starts to = reduce the processsing time available for completing sucessful = calls.

Increasing the offered load further, you reach a = point where all the processing time is used to reject IAMs, and there = is no sucessful traffic. The solution is to request adjacent nodes to = reduce the offered load, hopefully stabilising it at the point at which = all messages are sucessfully processed.

In my view, this is not a very good design, because = the exchange is relying on other elements in order to maintain its own = integrity. If those other elements do not behave as expected, then the = capacity of the congested element drops.

As I understand it, in SIP, messages can just be = dropped if they cannot be processed. There is potentially no processor = load associated with dropping the packet. This causes the sender to = back-off on retransmits (the sender doesn't see any difference between = network congestion and nodal overload).

I know this is a bit of a simplistic view, but I'm = sure someone will correct me if it's completely wrong :-)

...Mark

------_=_NextPart_001_01C2396C.D966E2C8-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 12:01:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04810 for ; Thu, 1 Aug 2002 12:01:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06212 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:02:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03342; Thu, 1 Aug 2002 11:33:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03304 for ; Thu, 1 Aug 2002 11:33:03 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03864 for ; Thu, 1 Aug 2002 11:31:54 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g719g2130331; Thu, 1 Aug 2002 04:42:07 -0500 Subject: RE: [Sip] REFER and dialogs terminated by BYE From: Robert Sparks To: Sriram Parameswar Cc: "'Pekka Pessi'" , sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Aug 2002 10:31:43 -0500 Message-Id: <1028215909.1247.2.camel@dhcp173.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit No. The subscription relationship and invite relationship are independent. This is the same as multiple SUBSCRIBEs to different events in the same INVITE dialog. The subscription lifetimes are independent from each other and from the lifetime of the INVITE association. As Adam pointed out - the subscription ends with a NOTIFY with a Subscription-State of terminated. RjS On Thu, 2002-08-01 at 09:38, Sriram Parameswar wrote: > Good question - my initial reaction would be that the receipt of the BYE > would terminate the Implicit Subscription just as a 481 may be used to > terminate subscriptions. Further - no NOTIFYs will be sent on the > terminated subscription. > > Regards, > > Sriram > > -----Original Message----- > From: Pekka Pessi [ mailto:Pekka.Pessi@nokia.com > ] > Sent: Thursday, August 01, 2002 8:39 AM > To: sip@ietf.org > Subject: [Sip] REFER and dialogs terminated by BYE > > > Hello, > > Let's say a REFER is used to transfer an existing call. REFER is > > sent using the existing dialog. Now, what should happen to the > dialog and the subscription(s) when either end uses BYE to > terminate the original call before the subscription(s) created > by REFER have terminated? > > BR, > > Pekka > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Thu Aug 1 12:04:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04977 for ; Thu, 1 Aug 2002 12:04:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06483 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:05:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03592; Thu, 1 Aug 2002 11:37:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03562 for ; Thu, 1 Aug 2002 11:37:09 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03963 for ; Thu, 1 Aug 2002 11:36:00 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g719kA130335; Thu, 1 Aug 2002 04:46:10 -0500 Subject: RE: [Sip] REFER and dialogs terminated by BYE From: Robert Sparks To: Sriram Parameswar Cc: "'Pekka Pessi'" , sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Aug 2002 10:35:49 -0500 Message-Id: <1028216149.1246.5.camel@dhcp173.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit To save people from asking where this is described, the following appears on page 19 of rfc3265: Multiple subscriptions can be associated with a single dialog. Subscriptions may also exist in dialogs associated with INVITE- created application state and other application state created by mechanisms defined in other specifications. These sets of application state do not interact beyond the behavior described for a dialog (e.g., route set handling). A subscription is destroyed when a notifier sends a NOTIFY request with a "Subscription-State" of "terminated". A subscriber may send a SUBSCRIBE request with an "Expires" header of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY with a "Subscription-State" of "terminated" is sent. If a subscription's destruction leaves no other application state associated with the dialog, the dialog terminates. The destruction of other application state (such as that created by an INVITE) will not terminate the dialog if a subscription is still associated with that dialog. Note that the above behavior means that a dialog created with an INVITE does not necessarily terminate upon receipt of a BYE. Similarly, in the case that several subscriptions are associated with a single dialog, the dialog does not terminate until all the subscriptions in it are destroyed. RjS On Thu, 2002-08-01 at 09:38, Sriram Parameswar wrote: > Good question - my initial reaction would be that the receipt of the BYE > would terminate the Implicit Subscription just as a 481 may be used to > terminate subscriptions. Further - no NOTIFYs will be sent on the > terminated subscription. > > Regards, > > Sriram > > -----Original Message----- > From: Pekka Pessi [ mailto:Pekka.Pessi@nokia.com > ] > Sent: Thursday, August 01, 2002 8:39 AM > To: sip@ietf.org > Subject: [Sip] REFER and dialogs terminated by BYE > > > Hello, > > Let's say a REFER is used to transfer an existing call. REFER is > > sent using the existing dialog. Now, what should happen to the > dialog and the subscription(s) when either end uses BYE to > terminate the original call before the subscription(s) created > by REFER have terminated? > > BR, > > Pekka > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Thu Aug 1 12:23:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05570 for ; Thu, 1 Aug 2002 12:23:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07311 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:24:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04602; Thu, 1 Aug 2002 11:57:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04565 for ; Thu, 1 Aug 2002 11:57:24 -0400 (EDT) Received: from hagrid.orange.co.uk (smtpout10.orange.co.uk [193.35.135.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04552 for ; Thu, 1 Aug 2002 11:56:15 -0400 (EDT) From: amish.chana@orange.co.uk Received: from bit.orange.co.uk (bit.orange.co.uk) by hagrid.orange.co.uk (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Aug 2002 17:00:35 +0100 Received: from ruddick (notes-gw.orange.co.uk [172.16.133.18]) by bit.orange.co.uk with SMTP id g71FuuP06425; Thu, 1 Aug 2002 16:56:56 +0100 (BST) X-Lotus-FromDomain: HTLUK To: "Mark Watson" cc: "Naidu, Venkata" , sip@ietf.org Message-ID: <80256C08.0057D71D.00@ruddick> Date: Thu, 1 Aug 2002 17:00:33 +0100 Subject: RE: [Sip] SIP Congestion Control Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mark, See my response below ....... ------------------------------------------ In my view, this is not a very good design, because the exchange is relying on other elements in order to maintain its own integrity. If those other elements do not behave as expected, then the capacity of the congested element drops. [Amish] Isn't this equivalent to the affected proxy or media server relying on other elements (proxies and UAs) to back-off in order to maintain its own integrity. What happens if those elements do not behave as expected? As I understand it, in SIP, messages can just be dropped if they cannot be processed. There is potentially no processor load associated with dropping the packet. [Amish] I disagree with that point. It's an implementation issue and the message may incur some processing load on the server. Furthermore it may not be advisable to discard just any SIP message. INVITEs can be discarded but ACKs and other messages should not be discarded. And in order to determine the message type you have to process the message. :-) This causes the sender to back-off on retransmits (the sender doesn't see any difference between network congestion and nodal overload). [Amish] But if there is a sufficiently large pool of UAs, this method may be of little help. It would be better to get the the intermediate proxies to reduce their INVITEs and not block messages from sessions already in progress. The 503 Service Unavailable may be an option as some have already commented. --Amish I know this is a bit of a simplistic view, but I'm sure someone will correct me if it's completely wrong :-) ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 12:27:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05840 for ; Thu, 1 Aug 2002 12:27:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07703 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:28:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06340; Thu, 1 Aug 2002 12:03:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06269 for ; Thu, 1 Aug 2002 12:03:06 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04854; Thu, 1 Aug 2002 12:01:56 -0400 (EDT) From: aroychow@hss.hns.com Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71G2Qj29728; Thu, 1 Aug 2002 12:02:28 -0400 (EDT) To: "Mark Watson" Cc: "'amish.chana@orange.co.uk'" , sip@ietf.org, sip-admin@ietf.org, "Naidu, Venkata" Subject: RE: [Sip] SIP Congestion Control MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 1 Aug 2002 12:02:24 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/01/2002 12:00:33 PM, Serialize complete at 08/01/2002 12:00:33 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I remember a discussion quite some time ago about congestion control in SIP. Just found its reference: http://www1.ietf.org/mail-archive/working-groups/sip/current/msg00143.html Personally, I think dropping messages should be only after you cant respond with 503 (so uacs can then use SRV to try alternate routes) regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 "Mark Watson" Sent by: sip-admin@ietf.org 08/01/2002 11:05 AM To: "'amish.chana@orange.co.uk'" , "Naidu, Venkata" cc: sip@ietf.org Subject: RE: [Sip] SIP Congestion Control > [Amish] My question applies to the case where possibly a > large number of SIP > INVITEs are being sent to a proxy or media server. They are > is overload since > they are unable to process such a large number of requests > simultaneously. This > is analogous to the case in the PSTN where an exchange is > unable to process a > large number of calls. In the PSTN this is dealt with using > the ISUP ACC to get > the adjacent nodes to throttle back their traffic. > I think there is an important difference between ISUP ACC and SIP in this respect. The ISUP ACC mechanism is based on a model of a non-distributed system in which the exchange attempts to provide a valid response to every ISUP IAM coming in. Starting from a point at which the exchange can fully process all messages sucessfully, as the offered load increases, the exchange starts to reject some IAMs with release due to overload. As the offered load increases further, the processing time used to send these rejections increases and starts to reduce the processsing time available for completing sucessful calls. Increasing the offered load further, you reach a point where all the processing time is used to reject IAMs, and there is no sucessful traffic. The solution is to request adjacent nodes to reduce the offered load, hopefully stabilising it at the point at which all messages are sucessfully processed. In my view, this is not a very good design, because the exchange is relying on other elements in order to maintain its own integrity. If those other elements do not behave as expected, then the capacity of the congested element drops. As I understand it, in SIP, messages can just be dropped if they cannot be processed. There is potentially no processor load associated with dropping the packet. This causes the sender to back-off on retransmits (the sender doesn't see any difference between network congestion and nodal overload). I know this is a bit of a simplistic view, but I'm sure someone will correct me if it's completely wrong :-) ...Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 12:52:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06931 for ; Thu, 1 Aug 2002 12:52:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09365 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:53:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07194; Thu, 1 Aug 2002 12:21:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07163 for ; Thu, 1 Aug 2002 12:21:27 -0400 (EDT) Received: from imo-r02.mx.aol.com (imo-r02.mx.aol.com [152.163.225.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05530 for ; Thu, 1 Aug 2002 12:20:18 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v33.5.) id d.128.154806c2 (3940); Thu, 1 Aug 2002 12:20:32 -0400 (EDT) Message-ID: <128.154806c2.2a7ab9d0@aol.com> Date: Thu, 1 Aug 2002 12:20:32 EDT Subject: Re: [Sip] SIP Congestion Control To: mwatson@nortelnetworks.com, amish.chana@orange.co.uk, Venkata.Naidu@marconi.com CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_128.154806c2.2a7ab9d0_boundary" X-Mailer: AOL 6.0 for Windows US sub 353 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_128.154806c2.2a7ab9d0_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/1/02 11:07:29 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes: > In my view, this is not a very good design, because the exchange is relying > on other elements in order to maintain its own integrity. If those other > elements do not behave as expected, then the capacity of the congested > element drops. > It is impossible to operate a network without one element being able to rely on others to behave properly. Especially for overload control. Simply dropping packets when you can't handle all of them isn't a good design, since you don't know which ones to drop and it just causes the sender to try again. Deciding which to drop requires some processing. While this processing can be kept to the minimum (like by looking at a drop precedence in the header), it is always better long-term to rely on someone else to stop sending the overload. Dropping is always the last resort. Mike Pierce Artel --part1_128.154806c2.2a7ab9d0_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/1/02 11:07:29 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes:


In my view, this is not a very good design, because the exchange is relying on other elements in order to maintain its own integrity. If those other elements do not behave as expected, then the capacity of the congested element drops.


It is impossible to operate a network without one element being able to rely on others to behave properly. Especially for overload control. Simply dropping packets when you can't handle all of them isn't a good design, since you don't know which ones to drop and it just causes the sender to try again. Deciding which to drop requires some processing. While this processing can be kept to the minimum (like by looking at a drop precedence in the header), it is always better long-term to rely on someone else to stop sending the overload. Dropping is always the last resort.

Mike Pierce
Artel
--part1_128.154806c2.2a7ab9d0_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 12:56:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07100 for ; Thu, 1 Aug 2002 12:56:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09569 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:58:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07047; Thu, 1 Aug 2002 12:18:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06987 for ; Thu, 1 Aug 2002 12:18:34 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05457; Thu, 1 Aug 2002 12:17:24 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g71GIWX03124; Thu, 1 Aug 2002 18:18:32 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g71GIV109239; Thu, 1 Aug 2002 18:18:31 +0200 (MEST) Received: from cs.columbia.edu ([139.21.148.222]) by mail-y.mchp.siemens.de with ESMTP id g71GIVcH024946; Thu, 1 Aug 2002 18:18:31 +0200 (MET DST) Message-ID: <3D495F1B.8050100@cs.columbia.edu> Date: Thu, 01 Aug 2002 12:17:31 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aroychow@hss.hns.com CC: Mark Watson , "'amish.chana@orange.co.uk'" , sip@ietf.org, sip-admin@ietf.org, "Naidu, Venkata" Subject: Re: [Sip] SIP Congestion Control References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Remember also that TCP offers flow control, so that the upstream proxy will be throttled automatically. No packets lost and standard backpressure. aroychow@hss.hns.com wrote: > I remember a discussion quite some time ago about congestion control in > SIP. Just found its reference: > > http://www1.ietf.org/mail-archive/working-groups/sip/current/msg00143.html > > Personally, I think dropping messages should be only after you cant > respond with 503 (so uacs can then use SRV to try alternate routes) > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 12:57:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07165 for ; Thu, 1 Aug 2002 12:57:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09611 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 12:58:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08443; Thu, 1 Aug 2002 12:35:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08413 for ; Thu, 1 Aug 2002 12:35:28 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (h2s128a211n47.user.nortelnetworks.com [47.211.128.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06154 for ; Thu, 1 Aug 2002 12:34:18 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71GYeZ12292; Thu, 1 Aug 2002 17:34:41 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 17:34:40 +0100 Message-ID: From: "Mark Watson" To: "'Mpierce1@aol.com'" , amish.chana@orange.co.uk, Venkata.Naidu@marconi.com Cc: sip@ietf.org Subject: RE: [Sip] SIP Congestion Control Date: Thu, 1 Aug 2002 17:34:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23979.5312B55A" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23979.5312B55A Content-Type: text/plain Mike, I agree that dropping is always a last resort. My point was just that the overall system is more robust if individual nodes are integral in their own right i.e. they can keep on working, and doing useful work, without having to rely on other nodes performing certain functions. I'm just saying that you should not rely on adjacent in order to prevent your node failing altogether, especially when those nodes themselves may also be subject to overload. ACC is by no means universally used within the PSTN. It is a mechanism to optimise throughput during overload, not a mechanism to ensure the basic integrity of the exchanges. Of course if you have more messages than capacity, it's good to have ways of determining which messages most deserve your attention i.e. which will most likely lead to completion of calls. ...Mark -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: 01 August 2002 17:21 To: Watson, Mark [MOP:EP10:EXCH]; amish.chana@orange.co.uk; Venkata.Naidu@marconi.com Cc: sip@ietf.org Subject: Re: [Sip] SIP Congestion Control In a message dated 8/1/02 11:07:29 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes: In my view, this is not a very good design, because the exchange is relying on other elements in order to maintain its own integrity. If those other elements do not behave as expected, then the capacity of the congested element drops. It is impossible to operate a network without one element being able to rely on others to behave properly. Especially for overload control. Simply dropping packets when you can't handle all of them isn't a good design, since you don't know which ones to drop and it just causes the sender to try again. Deciding which to drop requires some processing. While this processing can be kept to the minimum (like by looking at a drop precedence in the header), it is always better long-term to rely on someone else to stop sending the overload. Dropping is always the last resort. Mike Pierce Artel ------_=_NextPart_001_01C23979.5312B55A Content-Type: text/html
Mike,
 
I agree that dropping is always a last resort. My point was just that the overall system is more robust if individual nodes are integral in their own right i.e. they can keep on working, and doing useful work, without having to rely on other nodes performing certain functions.
 
I'm just saying that you should not rely on adjacent in order to prevent your node failing altogether, especially when those nodes themselves may also be subject to overload.
 
ACC is by no means universally used within the PSTN. It is a mechanism to optimise throughput during overload, not a mechanism to ensure the basic integrity of the exchanges.
 
Of course if you have more messages than capacity, it's good to have ways of determining which messages most deserve your attention i.e. which will most likely lead to completion of calls.
 
...Mark
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: 01 August 2002 17:21
To: Watson, Mark [MOP:EP10:EXCH]; amish.chana@orange.co.uk; Venkata.Naidu@marconi.com
Cc: sip@ietf.org
Subject: Re: [Sip] SIP Congestion Control

In a message dated 8/1/02 11:07:29 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes:


In my view, this is not a very good design, because the exchange is relying on other elements in order to maintain its own integrity. If those other elements do not behave as expected, then the capacity of the congested element drops.


It is impossible to operate a network without one element being able to rely on others to behave properly. Especially for overload control. Simply dropping packets when you can't handle all of them isn't a good design, since you don't know which ones to drop and it just causes the sender to try again. Deciding which to drop requires some processing. While this processing can be kept to the minimum (like by looking at a drop precedence in the header), it is always better long-term to rely on someone else to stop sending the overload. Dropping is always the last resort.

Mike Pierce
Artel
------_=_NextPart_001_01C23979.5312B55A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 1 13:19:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08123 for ; Thu, 1 Aug 2002 13:19:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11004 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 13:20:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08956; Thu, 1 Aug 2002 12:45:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08892 for ; Thu, 1 Aug 2002 12:45:56 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06519; Thu, 1 Aug 2002 12:44:46 -0400 (EDT) From: aroychow@hss.hns.com Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71GjBj14179; Thu, 1 Aug 2002 12:45:11 -0400 (EDT) To: Henning Schulzrinne Cc: "'amish.chana@orange.co.uk'" , Mark Watson , sip@ietf.org, sip-admin@ietf.org, "Naidu, Venkata" Subject: Re: [Sip] SIP Congestion Control {offside} MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 1 Aug 2002 12:45:09 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/01/2002 12:43:15 PM, Serialize complete at 08/01/2002 12:43:15 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org As an offside, I had bookmarked two papers related to TCP congestion control - the latter of which also discusses modifications to the TCP stack to avoid some of the attacks describes ( I hear linux kernel 2.2 onwards already made some of these changes - not sure though) "Chaotic Nature of TCP Congestion Control" http://www.ieee-infocom.org/2000/papers/74.pdf "TCP Congestion Control with a Misbehaving Receiver" http://www.cs.washington.edu/homes/savage/papers/CCR99.pdf Worth a read for folks who are interested. -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Henning Schulzrinne 08/01/2002 12:17 PM To: aroychow@hss.hns.com cc: Mark Watson , "'amish.chana@orange.co.uk'" , sip@ietf.org, sip-admin@ietf.org, "Naidu, Venkata" Subject: Re: [Sip] SIP Congestion Control Remember also that TCP offers flow control, so that the upstream proxy will be throttled automatically. No packets lost and standard backpressure. aroychow@hss.hns.com wrote: > I remember a discussion quite some time ago about congestion control in > SIP. Just found its reference: > > http://www1.ietf.org/mail-archive/working-groups/sip/current/msg00143.html > > Personally, I think dropping messages should be only after you cant > respond with 503 (so uacs can then use SRV to try alternate routes) > DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Aug 1 22:43:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25566 for ; Thu, 1 Aug 2002 22:43:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08016 for sip-archive@odin.ietf.org; Thu, 1 Aug 2002 22:44:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06392; Thu, 1 Aug 2002 22:18:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06365 for ; Thu, 1 Aug 2002 22:18:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24377 for ; Thu, 1 Aug 2002 22:16:51 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g722HThI027322 for ; Thu, 1 Aug 2002 19:17:29 -0700 (PDT) Received: from ARUNVENKW2K1 (sjc-vpn3-593.cisco.com [10.21.66.81]) by sponge.cisco.com (Mirapoint) with SMTP id ABE01991; Thu, 1 Aug 2002 21:17:28 -0500 (CDT) From: "Arunachalam Venkatraman" To: Date: Thu, 1 Aug 2002 21:21:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <1028216149.1246.5.camel@dhcp173.dfw.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] RFC3261: is missing a reference to To tag when Resubmitting a request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit RFC3261 is silent on the matter of To tag when a request is to be resubmitted. In section 8.1.3.5 Processing 4xx Responses, it is said - >>>>>>>>>>>>> In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. <<<<<<<<<<<<< Now, a proxy returning a 407, is acting as a UAS and will add a To tag to that response creating a dialog (of sorts, since receipt of 407 terminates that dialog). When the request is resubmitted with credentials, the To tag should be omitted in addition to the above requirements on Call-Id, From and CSeq thereby initiating a new dialog. Maybe this is the only logical conclusion from the definition of a dialog and from other portions of the protocol specification. I believe there is some value to expressing this explicitly. Now, in general, the UAC has no way of knowing if the final 4xx response came from a target UAS or from an intermediary proxy. So, the general rule must be to always drop the To tag from the previous response when resubmitting a request. The sip call flow examples document (draft-ietf-sip-call-flows-05.txt) does demonstrate this in 3.1.2 Successful SIP to SIP through two proxies. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Aug 2 06:42:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13156 for ; Fri, 2 Aug 2002 06:42:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA06272 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 06:43:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04919; Fri, 2 Aug 2002 06:15:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04890 for ; Fri, 2 Aug 2002 06:15:51 -0400 (EDT) Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12744 for ; Fri, 2 Aug 2002 06:14:40 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix1-2.free.fr (Postfix) with ESMTP id 940E0AB1F1 for ; Fri, 2 Aug 2002 12:15:49 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 20D466411D; Fri, 2 Aug 2002 12:15:49 +0200 (MEST) To: sip@ietf.org Message-ID: <1028283349.3d4a5bd51274e@imp.free.fr> Date: Fri, 02 Aug 2002 12:15:49 +0200 (MEST) From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 64.208.49.160 Content-Transfer-Encoding: 8bit Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sirs, I am searching for the minutes of the second SIP session of the 54th meeting. Is there someone that can help me? Thank you for your answer. Best regards, Patrick _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Aug 2 06:55:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13321 for ; Fri, 2 Aug 2002 06:55:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA06605 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 06:56:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05137; Fri, 2 Aug 2002 06:26:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05109 for ; Fri, 2 Aug 2002 06:26:43 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12828 for ; Fri, 2 Aug 2002 06:25:27 -0400 (EDT) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g72AKWm24787; Fri, 2 Aug 2002 15:50:33 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C09.00394768 ; Fri, 2 Aug 2002 15:55:38 +0530 X-Lotus-FromDomain: HSSBLR To: patrick.mourot@online.fr cc: sip@ietf.org Message-ID: <65256C09.00394626.00@sampark.hss.hns.com> Date: Fri, 2 Aug 2002 15:55:34 +0530 Subject: Re: [Sip] (no subject) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Your search ends here : http://www.softarmor.com/sipwg/meets/ietf54/ :-) Subhash patrick.mourot@online.fr on 08/02/2002 03:45:49 PM To: sip@ietf.org cc: (bcc: Subhash Ullal Nayak/HSSBLR) Subject: [Sip] (no subject) Sirs, I am searching for the minutes of the second SIP session of the 54th meeting. Is there someone that can help me? Thank you for your answer. Best regards, Patrick _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 daemon@ns.ietf.org Fri Aug 2 07:05:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13626 for ; Fri, 2 Aug 2002 07:05:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07351 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 07:07:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06239; Fri, 2 Aug 2002 06:42:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06209 for ; Fri, 2 Aug 2002 06:42:16 -0400 (EDT) Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13130 for ; Fri, 2 Aug 2002 06:41:05 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-1.free.fr (Postfix) with ESMTP id EB2DD2AC; Fri, 2 Aug 2002 12:42:14 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id C58CF6411D; Fri, 2 Aug 2002 12:42:14 +0200 (MEST) To: sunayak@hss.hns.com Subject: Re: [Sip] (no subject) Message-ID: <1028284934.3d4a62069a47d@imp.free.fr> Date: Fri, 02 Aug 2002 12:42:14 +0200 (MEST) From: patrick.mourot@online.fr Cc: patrick.mourot@online.fr, sip@ietf.org References: <65256C09.00394626.00@sampark.hss.hns.com> In-Reply-To: <65256C09.00394626.00@sampark.hss.hns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 213.223.66.160 Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The 2nd session of SIP ???? Quoting sunayak@hss.hns.com: > > > > Your search ends here : http://www.softarmor.com/sipwg/meets/ietf54/ > > :-) > Subhash > > > > > > patrick.mourot@online.fr on 08/02/2002 03:45:49 PM > > To: sip@ietf.org > cc: (bcc: Subhash Ullal Nayak/HSSBLR) > > Subject: [Sip] (no subject) > > > > > Sirs, > > I am searching for the minutes of the second SIP session of > the 54th meeting. > Is there someone that can help me? > > Thank you for your answer. > > Best regards, > > Patrick > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@ns.ietf.org Fri Aug 2 07:21:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14241 for ; Fri, 2 Aug 2002 07:21:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07775 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 07:22:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06721; Fri, 2 Aug 2002 06:59:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06692 for ; Fri, 2 Aug 2002 06:59:13 -0400 (EDT) Received: from web13113.mail.yahoo.com (web13113.mail.yahoo.com [216.136.174.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13364 for ; Fri, 2 Aug 2002 06:58:02 -0400 (EDT) Message-ID: <20020802105912.5039.qmail@web13113.mail.yahoo.com> Received: from [203.200.20.226] by web13113.mail.yahoo.com via HTTP; Fri, 02 Aug 2002 03:59:12 PDT Date: Fri, 2 Aug 2002 03:59:12 -0700 (PDT) From: nangineni U To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Rel 5 Architecture Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hi , where can I find some information regarding the Rel 5 architecture significance? Iam interested in knowing the motivation behind developing Rel 5 architecture and its advantages over the Rel 4 architecture . anyone to help me? thanks ujjvala __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.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 daemon@ns.ietf.org Fri Aug 2 07:43:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14967 for ; Fri, 2 Aug 2002 07:43:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08964 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 07:45:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07728; Fri, 2 Aug 2002 07:19:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00102 for ; Thu, 1 Aug 2002 10:42:56 -0400 (EDT) Received: from mail.aastra.com (mail.aastra.com [216.94.98.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02400 for ; Thu, 1 Aug 2002 10:41:48 -0400 (EDT) Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 10:39:41 -0400 Message-ID: From: Jitender Arora To: sip@ietf.org Date: Thu, 1 Aug 2002 10:39:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] one doubt ... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all , I have one doubt regarding the handling of the ack in the INVITE server transaction completed state ..... In the specs it does not say anything about passing the ack to TU , when the ack is recieved in the completed state .......It does mention that if the ack is not recieved at all then we should inform this to the TU . So basically i wanted to know whether in the implementation should we pass the ack to the TU or we terminate the TU session after sending the 4xx/5xx/6xx messages to transaction layer to pass it to the client . Regards, Jitender. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 2 13:03:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26938 for ; Fri, 2 Aug 2002 13:03:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26561 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 13:04:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24312; Fri, 2 Aug 2002 12:29:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24281 for ; Fri, 2 Aug 2002 12:29:50 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25692 for ; Fri, 2 Aug 2002 12:28:38 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g72GTHAK005781; Fri, 2 Aug 2002 09:29:17 -0700 (PDT) Received: from open-131-161-248-87.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAP52061; Fri, 2 Aug 2002 09:28:11 -0700 (PDT) Date: Fri, 2 Aug 2002 09:29:30 -0700 Subject: Re: [Sip] draft-ietf-sip-privacy-general-04 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "ShavinderPal Singh" From: Rohan Mahy In-Reply-To: <89CFEE6120A0224EA07781892EC0B48B965658@esuims01.esamsungumit.com> Message-Id: <055419A1-A635-11D6-B79D-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The functionality you are looking for has been replaced by other work because the WG could not reach consensus on draft-ietf-sip-privacy-04 during working group last call. You may want to have a look at the comments on the mailing list in the first half of May, or for a concise snapshot, the notes on that topic from the Interim meeting May 6 and 7: http://www.softarmor.com/sipwg/meets/interim- may-02/notes/afternoon-day2-willis.html Essentially privacy and identity were split, and the identity mechanism was split into a short-term trust-based mechanism, and a long-term cryptographic mechanism. The relevant documents are listed below: draft-ietf-sip-privacy-general (approved by the IESG, now in RFC editor queue) draft-ietf-sipping-nai-reqs (approved by the IESG, now in RFC editor queue) draft-ietf-sip-asserted-identity (approved by the IESG, now in RFC editor queue) draft-peterson-sip-identity (now a WG item) thanks, -rohan On Tuesday, July 30, 2002, at 11:59 PM, ShavinderPal Singh wrote: > >> Hi, >> I am not able to find draft-ietf-sip-privacy-general-04 on ietf.org >> >> Can anyone help me find it on the net somewhere. I searched on the >> site. I could find only draft-ietf-sip-privacy-general-01. >> >> Thanks & Rgds >> s >> >> Samsung SDS Infotech. P Ltd. >> Ph.: 091-124-6383474 (e 254) >> _________________________________ >> "I am not suffering from insanity, >> I am enjoying every single minute of it!". >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 2 14:22:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29643 for ; Fri, 2 Aug 2002 14:22:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00954 for sip-archive@odin.ietf.org; Fri, 2 Aug 2002 14:23:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29240; Fri, 2 Aug 2002 13:57:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29214 for ; Fri, 2 Aug 2002 13:57:25 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28776 for ; Fri, 2 Aug 2002 13:56:13 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g72HuIrU020931; Fri, 2 Aug 2002 19:56:23 +0200 (MEST) Received: from ericsson.com (ppp25.lmf.ericsson.se [131.160.102.25]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g72Hu6a9011558; Fri, 2 Aug 2002 20:56:07 +0300 (EET DST) Message-ID: <3D4AC7C5.1289A8E3@ericsson.com> Date: Fri, 02 Aug 2002 20:56:21 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Manuel Moreno =?iso-8859-1?Q?Mart=EDn?= CC: sip@ietf.org, Gonzalo Camarillo Subject: Re: [Sip] Message body for 200 response References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Tambien puedes consultar "SIP demystified", escrito por un Gonzalo Camarillo. http://www.amazon.com/exec/obidos/ASIN/0071373403/qid=1028310794/sr=8-1/ref=sr_8_1/002-5657810-6933634 Saludos, Miguel Angel Manuel Moreno Martín wrote: > > I want to know more over the body of SIP messages. > > In the book "UNDERSTANDING THE SESSION INITIATION PROTOCOL", of Alan B. > Johnston (page 80), I have read : "For 200 OK responses to BYE, CANCEL, > INFO, and PRACK, a message body is not permitted" > > But now, in the RFC 3261 (SIP), page 33, I read: "All responses MAY include > a body" > > Please, I want to know more over this issue > > Thank you for your time > > 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 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 04:08:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04643 for ; Mon, 5 Aug 2002 04:08:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16889 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 04:09:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14236; Mon, 5 Aug 2002 03:19:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14204 for ; Mon, 5 Aug 2002 03:19:23 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03803 for ; Mon, 5 Aug 2002 03:18:08 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g757Ctm09330; Mon, 5 Aug 2002 12:42:55 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C0C.00282021 ; Mon, 5 Aug 2002 12:48:16 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org cc: jon.peterson@neustar.biz Message-ID: <65256C0C.00281E89.00@sampark.hss.hns.com> Date: Mon, 5 Aug 2002 12:48:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] privacy service :draft-ietf-sip-privacy-general-01..(.Resending) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm resubmitting this mail to the list as I did not receive any comments in response. --------------------------------------------------------------------------- ------------- I have a comment on the privacy services and their support on proxy or other servers. If privacy services defined in terms of different levels can be supported/not supported by different proxy servers, then one can also assume that probably these may be activated/deactivated on existing servers in the network. If we accept this scenario, then the draft needs to address situations like the following: 1.A proxy server which is performing levels A out of a total levels A,B requested by the UA, now is ready to activate level B. What should it do to the session for which it is only performing level A?(case activation of a privacy level) 2.A proxy server which is performing levels A out of a total levels A,B requested by the UA, now wants to deactive level A. What should it do to the session for which it is only performing level A?(case deactivation of a privacy level) Should it reroute future messages through another server which supports both A,B?Or should it only stop removing the prev-value so that subsequent servers start to perform the privacy service A? Or should deactivation of a level on a server be allowed only when the level in question is not in use? IMHO such scenarios may be likely, and some guidelines or explanations should be provided in the draft to cover them. Comments? regards Harsh Bhondwe Hughes Software Systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 04:12:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04737 for ; Mon, 5 Aug 2002 04:12:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17029 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 04:13:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14835; Mon, 5 Aug 2002 03:30:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14798 for ; Mon, 5 Aug 2002 03:30:33 -0400 (EDT) Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03955 for ; Mon, 5 Aug 2002 03:29:18 -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.5762.3 Date: Mon, 5 Aug 2002 13:00:57 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B1398CB@esuims01.esamsungumit.com> Thread-Topic: TimerE Thread-Index: AcI8Ugn9ejARM1ywTKi1QaRpzWdKDg== From: "Raj Kumar" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA14799 Subject: [Sip] TimerE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi all, 1) In NICT when state moves from Trying to Proceeding, Shall the Timer E and TimerF to be restarted again. or Timer E and Timer F should be there as when started in Trying state. 2) In NICT when provisional response is received repeatedly in Proceeding state, Do The timers E and F need to be restarted again? Raj. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 09:04:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11292 for ; Mon, 5 Aug 2002 09:04:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01014 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 09:05:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29023; Mon, 5 Aug 2002 08:28:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28989 for ; Mon, 5 Aug 2002 08:28:44 -0400 (EDT) Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09797 for ; Mon, 5 Aug 2002 08:27:22 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g75CREx14250; Mon, 5 Aug 2002 12:27:29 GMT Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 07:27:09 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A037F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'hbhondwe@hss.hns.com'" Cc: "'sip@ietf.org'" Date: Mon, 5 Aug 2002 07:27:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: privacy service :draft-ietf-sip-privacy-general-01..(.Resendi ng) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This draft has already passed IETF last call and has been approved by the IESG, although it has not yet appeared in the RFC repository. In other words, it may be a little late to make substantial changes to the current revision. That much said, I would still like to speak to your considerations below. I don't see a lot of value in defining behavior for a privacy service when it suddenly learns or forgets privacy functions on-the-fly while a dialog (or worse, a transaction) is in progress - to my knowledge, we don't tend to worry about this property for other option-tag-based features in SIP. I don't think we need to introduce the idea that privacy services may change the privacy qualities of a dialog that is in progress - any more than a SIP extension needs to define what happens if a previously-compliant proxy stops supporting the extension in the middle of a transaction or dialog. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: hbhondwe@hss.hns.com [mailto:hbhondwe@hss.hns.com] > Sent: Monday, August 05, 2002 12:18 AM > To: sip@ietf.org > Cc: jon.peterson@neustar.biz > Subject: privacy service > :draft-ietf-sip-privacy-general-01..(.Resending) > > > > > I'm resubmitting this mail to the list as I did not receive > any comments in > response. > > > -------------------------------------------------------------- > ------------- > ------------- > > > I have a comment on the privacy services and their support on proxy or > other servers. > > If privacy services defined in terms of different levels can be > supported/not supported by different proxy servers, then one can also > assume that probably these may be activated/deactivated on > existing servers > in the network. If we accept this scenario, then the draft > needs to address > situations like the following: > 1.A proxy server which is performing levels A out of a total > levels A,B > requested by the UA, now is ready to activate level B. What > should it do to > the session for which it is only performing level A?(case > activation of a > privacy level) > 2.A proxy server which is performing levels A out of a total > levels A,B > requested by the UA, now wants to deactive level A. What > should it do to > the session for which it is only performing level A?(case > deactivation of a > privacy level) Should it reroute future messages through > another server > which supports both A,B?Or should it only stop removing the > prev-value so > that subsequent servers start to perform the privacy service > A? Or should > deactivation of a level on a server be allowed only when the level in > question is not in use? > > IMHO such scenarios may be likely, and some guidelines or explanations > should be provided in the draft to cover them. > > Comments? > > regards > Harsh Bhondwe > Hughes Software Systems > > > > > > > This message is proprietary to Hughes Software Systems > Limited (HSS) and is > intended solely for the use of the individual to whom it is > addressed. It > may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is > intended. If > you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are > notified that > you are strictly prohibited from using, copying, altering, or > disclosing > the contents of this message. HSS accepts no responsibility > for loss or > damage arising from the use of the information transmitted by > this email > including damage from virus. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 10:22:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14935 for ; Mon, 5 Aug 2002 10:22:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05159 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 10:23:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00025; Mon, 5 Aug 2002 08:45:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14834 for ; Fri, 2 Aug 2002 19:24:40 -0400 (EDT) Received: from harp.interval.com ([64.94.69.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11104; Fri, 2 Aug 2002 19:23:20 -0400 (EDT) Received: by harp.interval.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 16:20:35 -0700 Message-ID: <50750ECDD09ED411AF9A00508B6A823B7E4391@harp.interval.com> From: Kathy Kwan To: "'sip@ietf.org'" , "'mmusic@ietf.org'" Cc: Kathy Kwan Date: Fri, 2 Aug 2002 16:20:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A7B.33DD1330" Subject: [Sip] Port changeability in response to Invite -- expected behavior? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23A7B.33DD1330 Content-Type: text/plain To the SIP/MMUSIC community, I was looking at the method proposed by Rosenberg and Schulzrinne in the IETF Internet Draft entitled "Models for Multiparty Conferencing in SIP" (dated July 2002, expires Jan 2003), Section 7, entitled "Centralized Signaling, Distributed Media". This method describes the conferencing case where a server controls the SIP connections with all participants, and uses third party call control to enable media connections to go directly between the participants. Hence, the signaling is centralized, but media is distributed. In order for the method to work, an inherent assumption is made that the original ports do not change in the response to an Invite. Two examples of this assumption are shown in the call flow diagram of "Centralized Signaling, Distributed Media" Figure 7: (1) If a participant is taken off hold, the participant cannot change its ports in its response. In Figure 7, participant D is taken off hold in the very last Invite transaction between D and the server. It is assumed that D does not change its ports D1,D2, and D3 in its Invite 200 OK response. (Perhaps there is a way to interleave invites using provisional responses that could fix this particular case, but if that exists, the response could be delayed by as long as it takes to receive the responses from all other participants in the conference.) (2) If a participant receives a re-Invite for any reason, the participant must maintain its original offered ports in the response. In Figure 7, parties A, B and C are assumed to not change their original ports when they receive a re-Invite from the server asking for an additional port for D. According to Figure 7, A, B, and C are not put on hold when D arrives, so this case is distinct from (1) above. My questions are: (3) What assumptions can be made about the ports being able to change in the response to an Invite? Is there documentation of this in any RFCs? Perhaps a media attribute could be used to request that the ports don't change if it is not already implied in either of the cases above? (4) There are two ways to convey hold described below. Is the expectation for port behavior the same for both cases of hold? The original way to convey hold is to set the IP address to 0.0.0.0. This case does not require RTCP to be sent during the hold period. A new method to convey hold is to use the media attributes "a=inactive", "a=sendonly" or "a=recvonly", depending on the direction of the hold. Because of the different implications for the hold methods, particularly for RTCP, I am asking this question with both methods in mind. Thank you in advance for your comments. Regards, Kathy Kwan Interval Media ------_=_NextPart_001_01C23A7B.33DD1330 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

To the SIP/MMUSIC community,

 

I was looking at the method proposed by Rosenberg and Schulzrinne in the IETF Internet Draft entitled "Models for Multiparty Conferencing in SIP" (dated July 2002, expires Jan 2003), Section 7, entitled "Centralized Signaling, Distributed Media".    This method describes the conferencing case where a server = controls the SIP connections with all participants, and uses third party call = control to enable media connections to go directly between the participants.   Hence, the signaling is centralized, but media is distributed.  In order for the method to work, an inherent assumption is made = that the original ports do not change in the response to an Invite.  Two examples of this = assumption are shown in the call flow diagram of "Centralized Signaling, Distributed Media" Figure 7:

 

(1)      If a participant is taken = off hold, the participant cannot change its ports in its = response.

 

In Figure 7, = participant  D is taken off hold in the very last Invite transaction between D and the server.   It = is assumed that D does not change its ports D1,D2, and D3 in its Invite 200 OK response.   =

 

(Perhaps = there is a way to interleave invites using provisional responses that could fix this particular case, but if that exists, the response could be delayed by = as long as it takes to receive the responses from all other participants in the conference.)

 

(2)      If a participant receives = a re-Invite for any reason, the participant must maintain its original = offered ports in the response.

 

In Figure 7, = parties A, B and C are assumed to not change their original ports when they receive = a re-Invite from the server asking for an additional port for D.   According to Figure 7, = A, B, and C are not put on hold when D arrives, so this case is distinct from (1) = above.     =

 

My questions are:

 

(3)      What assumptions can be = made about the ports being able to change in the response to an Invite?    Is there = documentation of this in any RFCs?   

 

Perhaps a media attribute = could be used to request that the ports don't change if it is not already = implied in either of the cases above?

 

(4)      There are two ways to = convey hold described below.   Is = the expectation for port behavior the same for both cases of = hold?

 

The original = way to convey hold is to set the IP address to 0.0.0.0.  This case does not require = RTCP to be sent during the hold period.   A new method to convey hold is to use the media attributes "a=3Dinactive", "a=3Dsendonly" or "a=3Drecvonly", depending on the direction of the hold.  Because of = the different implications for the hold methods, particularly for RTCP, I = am asking this question with both methods in mind.

 

Thank you in advance for your = comments.

 

Regards,

Kathy = Kwan

Interval Media

 

------_=_NextPart_001_01C23A7B.33DD1330-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 15:32:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28752 for ; Mon, 5 Aug 2002 15:32:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25137 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 15:34:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23630; Mon, 5 Aug 2002 15:03:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23599 for ; Mon, 5 Aug 2002 15:03:13 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27593 for ; Mon, 5 Aug 2002 15:02:00 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g75J2j309639 for ; Mon, 5 Aug 2002 14:02:45 -0500 From: "Dean Willis" To: Date: Mon, 5 Aug 2002 14:02:25 -0500 Message-ID: <00ed01c23cb2$a33722a0$eb036e3f@TXDWILLIS2> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Congestion Safety Draft Revised Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Based on list feedback and AD directions the SIP transport congestion safety draft has been revised and resubmitted under a WG title to the archives and should appear shortly. In the interimn, you may wish to review: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.xml I'd like to ask you to consider the relation to: http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe -ci-00.txt Specifically, these seem to refer to different aspects of congestion safety. Is some sort of convergence needed? If so, what and how? Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 15:32:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28766 for ; Mon, 5 Aug 2002 15:32:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25149 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 15:34:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22004; Mon, 5 Aug 2002 14:37:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21972 for ; Mon, 5 Aug 2002 14:36:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26386 for ; Mon, 5 Aug 2002 14:35:47 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g75IaR309489; Mon, 5 Aug 2002 13:36:28 -0500 From: "Dean Willis" To: , Subject: RE: [Sip] SIP Congestion Control Date: Mon, 5 Aug 2002 13:36:07 -0500 Message-ID: <00ea01c23cae$f73d4900$eb036e3f@TXDWILLIS2> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <80256C07.00559583.00@ruddick> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit amish.chana asked: > Does SIP support congestion/flow control methods during > application level processing overload? (e.g. something > equivalent to ISUP's ACC) > > This is typically for scenarios where there could be a burst > of calls (possibly due to some media stimulated event) and > hence a burst of SIP messages. The target of these messages > could either be a proxy server, voicemail server or some > other media server. Even if a reliable transport like TCP is used, it may be possible for messages to be delivered to an element faster than that element can process those message. This results in queueing-up incoming messages. Generally queue space is not infinite, and there is a related issue with retransmission timers. I've seen implementations that manage to handle this very effectively by having the overloaded element issue a 503 (Service Unavailable) response to new requests that it will be unable to process effectively. This can be combined with a Retry-After header to indicate a minimum delay that the requester must apply before resubmitting the request. There are also techniques whereby a proxy can start "ducking" by doing things like returning a 302 response redirecting the request to a load-balancing element instead of queueing the request. For example, assume a proxy server capable of processing 100 requests per second receives 200 requests per second. After 5 seconds, it has processed 500 requests accumulated a direct queue of 500 requests. Of course, some of the requests will have timed out and been retransmitted, increasing the queue further. Obviously, continuance in this kind of overload condition results in total meltdown, so we have to DO SOMETHING. This leads to a couple of design principles: 1) Stateful proxy servers should send provisional responses quickly, reducing retransmission. 2) When there are multiple identical requests in a queue, some sort of discard algorithm is needed to prevent redundant procesing. There are many design alternatives here, and management of this is a big factor I would consider when doing an evaluation of commercial proxy servers. 3) The proxy needs an awareness of its queue depth and processing rate, and needs to switch to 503 responses or some alternate mechanism (such as invoking a load balancer) when it detects an overload condition. All of these things are enabled by the protocol, but HOW to use them effectively for scaling and reliability management is beyond the scope of the SIP protocol specification, just as building large scale web servers is beyond the scope of the HTTP specification. This is a major differentiator between systems -- lots of people can implement the basic specification, but there aren't many people out there who have really thought through the usage of these elements in building large-scale systems. There are really big differences between the "research grade" free proxies or "workgroup" scale stuff you can get bundled with various operating systems and commercial scale architectures capable of supporting tens of millions of users. That's why the big stuff is expensive. Of course, not everything expensive actually works right, so ask questions carefully . . . And yes, this is the kind of thing that keeps me up nights. It's quite an interesting problem space. Lots of opportunity for graduate projects, I think. If you want to fund some research work here, let me know -- I may know people interested in pursuing it. -- 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 daemon@optimus.ietf.org Mon Aug 5 15:47:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29199 for ; Mon, 5 Aug 2002 15:47:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25673 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 15:48:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23961; Mon, 5 Aug 2002 15:08:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23930 for ; Mon, 5 Aug 2002 15:08:32 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27888 for ; Mon, 5 Aug 2002 15:07:19 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g75J85309696 for ; Mon, 5 Aug 2002 14:08:05 -0500 From: "Dean Willis" To: Date: Mon, 5 Aug 2002 14:07:45 -0500 Message-ID: <00ef01c23cb3$619da890$eb036e3f@TXDWILLIS2> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revised Service Route Discovery draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Following extended list discussion, we have revised the service route discovery draft towards standards track and resubmitted. It should appear in the archives shortly. In the meantime, please review: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-svcrtdisco-00.txt http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-svcrtdisco-00.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-svcrtdisco-00.xml I believe that the only changes made from the P-header informational draft that had already completed working group expert review were the elimination of the P- and some slight language cleanup relating to scope. Of course, this doesn't mean we didn't convolute entire sections accidentally, so please give it a read. I'd like to move this to a WGLC status fairly quickly. Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 5 17:22:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02726 for ; Mon, 5 Aug 2002 17:22:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00459 for sip-archive@odin.ietf.org; Mon, 5 Aug 2002 17:23:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28318; Mon, 5 Aug 2002 16:39:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28290 for ; Mon, 5 Aug 2002 16:39:18 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00901 for ; Mon, 5 Aug 2002 16:38:04 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g75Kd8pA063752; Mon, 5 Aug 2002 15:39:08 -0500 (CDT) Message-ID: <3D4EE231.6070601@dynamicsoft.com> Date: Mon, 05 Aug 2002 15:38:09 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] SIP Congestion Safety Draft Revised References: <00ed01c23cb2$a33722a0$eb036e3f@TXDWILLIS2> X-Enigmail-Version: 0.61.1.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Without making judmements on the technical merits of the khartabil draft (and on an admittedly quick read) it seems to me that it attempts to solve a somewhat different problem than the sip-congestsafe draft. I do not think they need to converge, and they may in fact be complementary. Dean Willis wrote: > Based on list feedback and AD directions the SIP transport congestion > safety draft has been revised and resubmitted under a WG title to the > archives and should appear shortly. In the interimn, you may wish to > review: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.html > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.xml > > > I'd like to ask you to consider the relation to: > > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe > -ci-00.txt > > Specifically, these seem to refer to different aspects of congestion > safety. Is some sort of convergence needed? If so, what and how? > > > Thanks, > > -- > Dean Willis > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Tue Aug 6 23:53:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10462 for ; Tue, 6 Aug 2002 23:52:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA21730 for sip-archive@odin.ietf.org; Tue, 6 Aug 2002 23:54:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20778; Tue, 6 Aug 2002 23:19:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20718 for ; Tue, 6 Aug 2002 23:19:03 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09767; Tue, 6 Aug 2002 23:17:48 -0400 (EDT) Received: from victorpc ([206.184.140.168]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g773Ix809832; Tue, 6 Aug 2002 23:18:59 -0400 From: "Victor Paulsamy" To: "Kathy Kwan" , , Subject: RE: [Sip] Port changeability in response to Invite -- expected behavior? Date: Tue, 6 Aug 2002 20:14:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C23D85.E4E34700" 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.50.4807.1700 Importance: Normal In-Reply-To: <50750ECDD09ED411AF9A00508B6A823B7E4391@harp.interval.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C23D85.E4E34700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cathy: Comments inline ... -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Kathy Kwan Sent: Friday, August 02, 2002 4:21 PM To: 'sip@ietf.org'; 'mmusic@ietf.org' Cc: Kathy Kwan Subject: [Sip] Port changeability in response to Invite -- expected behavior? To the SIP/MMUSIC community, I was looking at the method proposed by Rosenberg and Schulzrinne in the IETF Internet Draft entitled "Models for Multiparty Conferencing in SIP" (dated July 2002, expires Jan 2003), Section 7, entitled "Centralized Signaling, Distributed Media". This method describes the conferencing case where a server controls the SIP connections with all participants, and uses third party call control to enable media connections to go directly between the participants. Hence, the signaling is centralized, but media is distributed. In order for the method to work, an inherent assumption is made that the original ports do not change in the response to an Invite. Two examples of this assumption are shown in the call flow diagram of "Centralized Signaling, Distributed Media" Figure 7: (1) If a participant is taken off hold, the participant cannot change its ports in its response. In Figure 7, participant D is taken off hold in the very last Invite transaction between D and the server. It is assumed that D does not change its ports D1,D2, and D3 in its Invite 200 OK response. (Perhaps there is a way to interleave invites using provisional responses that could fix this particular case, but if that exists, the response could be delayed by as long as it takes to receive the responses from all other participants in the conference.) (2) If a participant receives a re-Invite for any reason, the participant must maintain its original offered ports in the response. In Figure 7, parties A, B and C are assumed to not change their original ports when they receive a re-Invite from the server asking for an additional port for D. According to Figure 7, A, B, and C are not put on hold when D arrives, so this case is distinct from (1) above. My questions are: (3) What assumptions can be made about the ports being able to change in the response to an Invite? Is there documentation of this in any RFCs? Perhaps a media attribute could be used to request that the ports don't change if it is not already implied in either of the cases above? All aspects of a session can be changed as a result of a reINVITE. In this example that you refere to, the address/port MUST NOT change. (4) There are two ways to convey hold described below. Is the expectation for port behavior the same for both cases of hold? The original way to convey hold is to set the IP address to 0.0.0.0. This case does not require RTCP to be sent during the hold period. A new method to convey hold is to use the media attributes "a=inactive", "a=sendonly" or "a=recvonly", depending on the direction of the hold. Because of the different implications for the hold methods, particularly for RTCP, I am asking this question with both methods in mind. The first one is (0.0.0.0) used by old UAs and using media attributes to convey hold status is used by new UAs (perhaps bis05 onwards). However, they do not imply anything with regards to the port that can otherwise be changed using a reINVITE Regards, --victor Thank you in advance for your comments. Regards, Kathy Kwan Interval Media ------=_NextPart_000_0008_01C23D85.E4E34700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cathy: Comments=20 inline ...
 
-----Original Message-----
From: sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of Kathy = Kwan
Sent:=20 Friday, August 02, 2002 4:21 PM
To: 'sip@ietf.org';=20 'mmusic@ietf.org'
Cc: Kathy Kwan
Subject: [Sip] Port = changeability in response to Invite -- expected = behavior?

To the SIP/MMUSIC=20 community,

 

I was looking at the method proposed by = Rosenberg and=20 Schulzrinne in the IETF Internet Draft = entitled=20 "Models for Multiparty Conferencing in SIP" (dated July 2002, expires = Jan=20 2003), Section 7, entitled "Centralized Signaling, Distributed = Media".    This method = describes the=20 conferencing case where a server controls the SIP connections with all = participants, and uses third party call control to enable media = connections to=20 go directly between the participants.   Hence, the signaling = is=20 centralized, but media is distributed. =20 In order for the method to work, an inherent assumption is made = that=20 the original ports do not change in the response to an Invite.  Two examples of this = assumption are=20 shown in the call flow diagram of "Centralized Signaling, Distributed = Media"=20 Figure 7:

 

(1)     =20 If a participant is taken = off=20 hold, the participant cannot change its ports in its = response.

 

In Figure 7, participant  D=20 is taken off hold in the very last Invite transaction between D and = the=20 server.   It is = assumed that D=20 does not change its ports D1,D2, and D3 in = its Invite=20 200 OK response.  =20

 

(Perhaps there is a way to = interleave=20 invites using provisional responses that could fix this particular = case, but=20 if that exists, the response could be delayed by as long as it takes = to=20 receive the responses from all other participants in the=20 conference.)

 

(2)     =20 If a participant receives = a=20 re-Invite for any reason, the participant must maintain its original = offered=20 ports in the response.

 

In Figure 7, parties A, B and = C are=20 assumed to not change their original ports when they receive a = re-Invite from=20 the server asking for an additional port for D.   According to Figure 7, = A, B, and=20 C are not put on hold when D arrives, so this case is distinct from = (1)=20 above.    =20

 

My questions = are:

 

(3)     =20 What assumptions can be = made=20 about the ports being able to change in the response to an Invite? =    Is there = documentation of=20 this in any RFCs?   

 

Perhaps=20 a media attribute could be used to request that the ports don't change = if it=20 is not already implied in either of the cases=20 above?

 

All aspects of a session can be = changed as a=20 result of a reINVITE. In this example that you refere to,=20 the address/port MUST=20 NOT change.

 

(4)     =20 There are two ways to = convey hold=20 described below.   = Is the=20 expectation for port behavior the same for both cases of = hold?

 

The original way to convey = hold is to set=20 the IP address to 0.0.0.0.  = This=20 case does not require RTCP to be sent during the hold period.   A new method to convey = hold is=20 to use the media attributes "a=3Dinactive", "a=3Dsendonly" or "a=3Drecvonly",=20 depending on the direction of the hold. =20 Because of the different implications for the hold methods,=20 particularly for RTCP, I am asking this question with both methods in=20 mind.

 

   =20 The first one is (0.0.0.0) used by old UAs and using = media=20 attributes to convey hold status is used by new UAs (perhaps = bis05=20 onwards). However, they do not imply anything with regards to the port = that=20 can otherwise be changed using a=20 reINVITE

 

Regards,

 

--victor

 

Thank you in advance for your=20 comments.

 

Regards,

Kathy=20 Kwan

Interval Media

 

------=_NextPart_000_0008_01C23D85.E4E34700-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 7 06:44:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12175 for ; Wed, 7 Aug 2002 06:44:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02854 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 06:45:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01537; Wed, 7 Aug 2002 06:15:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01506 for ; Wed, 7 Aug 2002 06:15:26 -0400 (EDT) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11684 for ; Wed, 7 Aug 2002 06:14:10 -0400 (EDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g77ADBp02672; Wed, 7 Aug 2002 13:13:11 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Wed, 7 Aug 2002 13:13:18 +0300 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E079BC364@ismail3.comverse.com> From: Fuxbruner Amihay To: sip-implementors@cs.columbia.edu, sip@ietf.org Cc: Neitman Ludmila , Barth Matan Date: Wed, 7 Aug 2002 13:13:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23DFB.0BCFB9E6" Subject: [Sip] Different payload type offer-answer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23DFB.0BCFB9E6 Content-Type: text/plain; charset="windows-1255" Hi all, draft-ietf-mmusic-sdp-offer-answer-02 section 5.1 reads the following: However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. How should the offerer react in case he can not change the payload type ? This looks strange since the call was established with initial media problems. Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse ------_=_NextPart_001_01C23DFB.0BCFB9E6 Content-Type: text/html; charset="windows-1255" Different payload type offer-answer

Hi all,

draft-ietf-mmusic-sdp-offer-answer-02 section 5.1 reads the following:

   However, for sendonly and sendrecv streams, the answer might indicate
   different payload type numbers for the same codecs, in which case,
   the offerer MUST send with the payload type numbers from the answer.

How should the offerer react in case he can not change the payload type ?
This looks strange since the call was established with initial media problems.

Thanks,

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

------_=_NextPart_001_01C23DFB.0BCFB9E6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 7 07:46:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13583 for ; Wed, 7 Aug 2002 07:46:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05651 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 07:47:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04073; Wed, 7 Aug 2002 07:22:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04041 for ; Wed, 7 Aug 2002 07:22:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12869; Wed, 7 Aug 2002 07:21:37 -0400 (EDT) Message-Id: <200208071121.HAA12869@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: Wed, 07 Aug 2002 07:21:37 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-compression-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Compressing the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-compression-00.txt Pages : 12 Date : 06-Aug-02 This document describes a mechanism to signal that compression is desired for one or more SIP messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-compression-00.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-compression-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-compression-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020806114900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-compression-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-compression-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020806114900.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 daemon@optimus.ietf.org Wed Aug 7 07:56:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13826 for ; Wed, 7 Aug 2002 07:56:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06033 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 07:58:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04153; Wed, 7 Aug 2002 07:23:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04118 for ; Wed, 7 Aug 2002 07:23:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12904; Wed, 7 Aug 2002 07:21:50 -0400 (EDT) Message-Id: <200208071121.HAA12904@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: Wed, 07 Aug 2002 07:21:50 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-congestsafe-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension to Assure Congestion Safety Author(s) : D. Willis, B. Campbell Filename : draft-ietf-sip-congestsafe-00.txt Pages : 11 Date : 06-Aug-02 The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines what it means for SIP nodes to be congestion safe and specifies an extension by which a SIP User Agent may require that its requests are treated in a congestion safe manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-00.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-congestsafe-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-congestsafe-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020806114922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-congestsafe-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-congestsafe-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020806114922.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 daemon@optimus.ietf.org Wed Aug 7 07:59:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14048 for ; Wed, 7 Aug 2002 07:59:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06452 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 08:01:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04113; Wed, 7 Aug 2002 07:23:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04085 for ; Wed, 7 Aug 2002 07:23:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12886; Wed, 7 Aug 2002 07:21:43 -0400 (EDT) Message-Id: <200208071121.HAA12886@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: Wed, 07 Aug 2002 07:21:43 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-scvrtdisco-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration Author(s) : D. Willis, B. Hoeneisen Filename : draft-ietf-sip-scvrtdisco-00.txt Pages : 15 Date : 06-Aug-02 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-00.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-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-scvrtdisco-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020806114910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-scvrtdisco-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-scvrtdisco-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020806114910.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 daemon@optimus.ietf.org Wed Aug 7 11:32:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23713 for ; Wed, 7 Aug 2002 11:32:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18151 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 11:34:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15429; Wed, 7 Aug 2002 10:57:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15400 for ; Wed, 7 Aug 2002 10:57:36 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21588 for ; Wed, 7 Aug 2002 10:56:21 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 7 Aug 2002 14:57:50 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] SIP Congestion Safety Draft Revised Date: Wed, 7 Aug 2002 15:59:01 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE018C2403@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] SIP Congestion Safety Draft Revised Thread-Index: AcI8wLG+tI25EpwpS6+JTExNuHDsgwBYHrlQ From: "James Undery" To: "Ben Campbell" , "Dean Willis" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA15401 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I'd agree with Ben, as I read Hisham's draft it mainly dealt with "congestion" at entities receiving/storing messages, under certain specific architectures (e.g. 3GPP). James > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Without making judmements on the technical merits of the > khartabil draft > (and on an admittedly quick read) it seems to me that it attempts to > solve a somewhat different problem than the sip-congestsafe > draft. I do > not think they need to converge, and they may in fact be > complementary. > > Dean Willis wrote: > > Based on list feedback and AD directions the SIP transport > congestion > > safety draft has been revised and resubmitted under a WG > title to the > > archives and should appear shortly. In the interimn, you may wish to > > review: > > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.txt > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.html > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.xml > > > > > > I'd like to ask you to consider the relation to: > > > > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe > -ci-00.txt > > Specifically, these seem to refer to different aspects of congestion > safety. Is some sort of convergence needed? If so, what and how? > > > Thanks, > > -- > Dean Willis > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Wed Aug 7 15:56:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06272 for ; Wed, 7 Aug 2002 15:56:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03674 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 15:57:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01801; Wed, 7 Aug 2002 15:12:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01735 for ; Wed, 7 Aug 2002 15:12:48 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04338; Wed, 7 Aug 2002 15:11:34 -0400 (EDT) From: aroychow@hss.hns.com Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g77JBxj21197; Wed, 7 Aug 2002 15:12:00 -0400 (EDT) To: "Ben Campbell" , "Dean Willis" , sip@ietf.org, sip-admin@ietf.org, jundery@ubiquity.net Subject: RE: [Sip] SIP Congestion Safety Draft Revised MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 7 Aug 2002 15:11:56 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/07/2002 03:10:05 PM, Serialize complete at 08/07/2002 03:10:05 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Actually after reading both I-Ds I feel they need to have a common baseline. Hisham's I-D deals with both network congestion as well as handling capacity of a UA that finally receives the message. He defines procedures for Proxy-Require, 5xx responses as well as the Max-Size header Dean/Ben's draft also defines similar operations (with some exceptions) Hisham's examples are 3G specific, but the same principles seem to be used in both. Therefore, I feel Hisham's draft should use the same terminology as this draft (or vice versa - whatever :-) -> it makes more sense to me that http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt defines common procedures for congestion control and http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe-ci-00.txt realizes it specifically for the 3G space. Hisham: The one thing I feel that can be dropped is the max-size token you define in the Contact header in REGISTER. Is it really useful ? Why not just stick to the UA responding with 5xx if its gets a big message instead of now requiring proxies to check this additional field before forwarding ? Some minor edits in http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt * Section 2: "protocol has not explicit mechanisms for avoiding..." s/not/no * Section 3: point 2: "Note that this is an uncomoon case" s/uncomoon/uncommon * Page 5, para after fanout diag: s/\</ Sent by: sip-admin@ietf.org 08/07/2002 10:59 AM To: "Ben Campbell" , "Dean Willis" cc: Subject: RE: [Sip] SIP Congestion Safety Draft Revised I'd agree with Ben, as I read Hisham's draft it mainly dealt with "congestion" at entities receiving/storing messages, under certain specific architectures (e.g. 3GPP). James > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Without making judmements on the technical merits of the > khartabil draft > (and on an admittedly quick read) it seems to me that it attempts to > solve a somewhat different problem than the sip-congestsafe > draft. I do > not think they need to converge, and they may in fact be > complementary. > > Dean Willis wrote: > > Based on list feedback and AD directions the SIP transport > congestion > > safety draft has been revised and resubmitted under a WG > title to the > > archives and should appear shortly. In the interimn, you may wish to > > review: > > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.txt > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.html > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.xml > > > > > > I'd like to ask you to consider the relation to: > > > > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe > -ci-00.txt > > Specifically, these seem to refer to different aspects of congestion > safety. Is some sort of convergence needed? If so, what and how? > > > Thanks, > > -- > Dean Willis > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 8 04:28:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04940 for ; Thu, 8 Aug 2002 04:28:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17342 for sip-archive@odin.ietf.org; Thu, 8 Aug 2002 04:29:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13350; Thu, 8 Aug 2002 03:20:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13286 for ; Thu, 8 Aug 2002 03:20:41 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03102; Thu, 8 Aug 2002 03:19:27 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g787Wcf03064; Thu, 8 Aug 2002 10:32:38 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Aug 2002 10:20:39 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 8 Aug 2002 10:20:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] SIP Congestion Safety Draft Revised Date: Thu, 8 Aug 2002 10:20:36 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20475@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] SIP Congestion Safety Draft Revised Thread-Index: AcI+RnYCeOW03VBLR2Gb+dyNbWIPpwAYj3bw To: , , , , , X-OriginalArrivalTime: 08 Aug 2002 07:20:39.0201 (UTC) FILETIME=[18D9A910:01C23EAC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA13289 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Dean/Ben's I-D says: if a proxy detects that a request is too large and it can't forward it with a congestion safe transport protocol, the proxy rejects the request. My I-D says: well, you can either reject it (referring to the I-D above), or perform content indirection. The I-D also introduces the capability where a UA can reject a request (max-size header) or ask the home proxy to do something about it before it even gets to the UA (max-size param). I guess Arjun is talking about the latter part of the previous sentence. We added the max-size parameter to the contact header to save bandwidth (error response followed by another request and response) if the UA knows at registration time that it can't handle message size larger than x. Regards, Hisham > -----Original Message----- > From: ext aroychow@hss.hns.com [mailto:aroychow@hss.hns.com] > Sent: Wednesday, August 07, 2002 10:12 PM > To: Ben Campbell; Dean Willis; sip@ietf.org; sip-admin@ietf.org; > jundery@ubiquity.net > Subject: RE: [Sip] SIP Congestion Safety Draft Revised > > > Actually after reading both I-Ds I feel they need to have a common > baseline. > > Hisham's I-D deals with both network congestion as well as handling > capacity of a UA that finally receives the message. > He defines procedures for Proxy-Require, 5xx responses as well as the > Max-Size header > > Dean/Ben's draft also defines similar operations (with some > exceptions) > > Hisham's examples are 3G specific, but the same principles > seem to be used > in both. Therefore, I feel Hisham's draft should > use the same terminology as this draft (or vice versa - > whatever :-) -> it > makes more sense to me that > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.txt > defines common procedures for congestion control > and > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-cong > estionsafe-ci-00.txt > realizes it specifically for the 3G space. > > Hisham: The one thing I feel that can be dropped is the > max-size token you > define in the Contact header in REGISTER. Is it really useful ? > Why not just stick to the UA responding with 5xx if its gets > a big message > instead of now requiring proxies to check this additional field > before forwarding ? > > Some minor edits in > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > fe-00.txt > > * Section 2: "protocol has not explicit mechanisms for avoiding..." > s/not/no > > * Section 3: point 2: "Note that this is an uncomoon case" > s/uncomoon/uncommon > > * Page 5, para after fanout diag: s/\</ > regds > arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301-212-7860 (M): 240-997-0066 > > > > > "James Undery" > Sent by: sip-admin@ietf.org > 08/07/2002 10:59 AM > > > To: "Ben Campbell" , > "Dean Willis" > > cc: > Subject: RE: [Sip] SIP Congestion Safety Draft Revised > > > I'd agree with Ben, as I read Hisham's draft it mainly dealt with > "congestion" at entities receiving/storing messages, under certain > specific architectures (e.g. 3GPP). > > James > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Without making judmements on the technical merits of the > > khartabil draft > > (and on an admittedly quick read) it seems to me that it > attempts to > > solve a somewhat different problem than the sip-congestsafe > > draft. I do > > not think they need to converge, and they may in fact be > > complementary. > > > > Dean Willis wrote: > > > Based on list feedback and AD directions the SIP transport > > congestion > > > safety draft has been revised and resubmitted under a WG > > title to the > > > archives and should appear shortly. In the interimn, you > may wish to > > > review: > > > > > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > > fe-00.txt > > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > > fe-00.html > > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsa > > fe-00.xml > > > > > > > > > I'd like to ask you to consider the relation to: > > > > > > > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-cong estionsafe > -ci-00.txt > > Specifically, these seem to refer to different aspects of congestion > safety. Is some sort of convergence needed? If so, what and how? > > > Thanks, > > -- > Dean Willis > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 8 04:28:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04957 for ; Thu, 8 Aug 2002 04:28:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17361 for sip-archive@odin.ietf.org; Thu, 8 Aug 2002 04:29:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15460; Thu, 8 Aug 2002 03:57:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15431 for ; Thu, 8 Aug 2002 03:56:58 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04114 for ; Thu, 8 Aug 2002 03:55:44 -0400 (EDT) From: lieve.bos@alcatel.be Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g787phN03670; Thu, 8 Aug 2002 09:51:43 +0200 Received: from alcatel.be ([138.203.33.19]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002080809562685:2229 ; Thu, 8 Aug 2002 09:56:26 +0200 Message-ID: <3D52242A.BA2CA977@alcatel.be> Date: Thu, 08 Aug 2002 09:56:26 +0200 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/08/2002 09:56:26, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/08/2002 09:56:27, Serialize complete at 08/08/2002 09:56:27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Sip] Anybody knows how long SIP call setup takes? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, 1) Does anybody know how long a SIP call setup take? I am particularly interested in the mobile case where there is for each user a P-CSCF (proxy SIP server in visited network) and S-CSCF (serving SIP server in home network) involved. 2) By how much does the call setup delay increase when the SIP session is established using the "assured QoS" model (i.e. when guarantee of end-to-end resource reservation is required before ringing is started). In this case more SIP messages (i.e. SIP 183, SIP UPDATE,...) are sent back and forth before ringing actually takes place. 3) In the particular case of third party call control (SIP application server setting up call between 2 endusers), does anyone have figures on how long that takes (preferably again in worst case - i.e. when using "assured QoS" model). 4) In all these cases getting the first INVITE through probably takes the longest. After the signalling "path" has been established between the two end hosts I guess the next SIP messages (e.g. Ringing, ACK,...) take less time to pass from one end to the other. Anyone any idea how long it takes for such a SIP message to travel one way between two end hosts? Thanks for your help, Lieve Bos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 8 05:25:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05929 for ; Thu, 8 Aug 2002 05:25:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20217 for sip-archive@odin.ietf.org; Thu, 8 Aug 2002 05:26:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18080; Thu, 8 Aug 2002 04:36:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18051 for ; Thu, 8 Aug 2002 04:36:22 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05111 for ; Thu, 8 Aug 2002 04:35:07 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g788a8Rb021373; Thu, 8 Aug 2002 10:36:08 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.102]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g788a7a9013750; Thu, 8 Aug 2002 11:36:07 +0300 (EET DST) Message-ID: <3D522D76.9134BC80@ericsson.com> Date: Thu, 08 Aug 2002 11:36:06 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Dean Willis , bcampbell@dynamicsoft.com CC: sip@ietf.org Subject: Re: [Sip] SIP Congestion Safety Draft Revised References: <00ed01c23cb2$a33722a0$eb036e3f@TXDWILLIS2> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have been reading this draft, and I have some questions and comments. 1) In section 4 I found this sentence: Proxies not recognizing a specific tag or unwilling to support the associated behavior MUST reject a request referencing that tag with a 420 response, which has the semantic "Unsupported". Although I agree with the technical contents, I believe that the normative text (proxy MUST return a 420 response with Unsupported header) is already covered in RFC 3261. I think is simply better not to specify the same procedure, and just refer to the actions described in RFC 3261. 2) Section 5 states: "Clearly the best thing to do is to use a more sophisticated transport protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and its associated proxy. If this is not feasible, it may be necessary to fall back to UDP. This is especially common in the case of low- capacity UAs such as those proposed for 3G wireless systems." I disagree with the example of the last sentence. I have been working for a while with the 3GPP standardization, and there is no reference to an exclusive usage of UDP in either terminals or proxies. As a background information, 3GPP TS 24.229 defines the SIP profile used by 3GPP. This specification "imports" RFC 3261 and a number of other RFCs. This means, that unless some optionality in RFC 3261 is made mandatory in 24.229, the text in RFC 3261 applies. Currently, there is not mention at all to the transport protocols in 24.229. This means that the text in RFC 3261 is applicable as it is. RFC 3261 says in section 18: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Conclusion: in 3GPP all the terminals and proxies MUST implement TCP and UDP, although they can implement other transport protocols. Now, coming back to the draft, I don't see the point of having such a long discussion about UAs that can't use TCP, because the case does not exist. If a devices is RFC 3261 compliant, it MUST implement TCP. 3) The last paragraph in section 5.1 reveals what I consider is an important problem: routing of SIP responses must follow the Via header, and that includes the transport protocol to the receiver of the request. This is a big problem, because a UA may send a short SIP request, that fits in a UDP packet, but the response may be significantly large, and it does not fit in there. It could be interesting to have a procedures to do either of these actions: a) The UA could signal in the Via header the set of transport protocols supported, so that the proxy which forwards the response could freely choose another protocol, if deemed. b) The UAS could use the procedures in section 5.3, Proxy Rejects Request That Would Require UDP Fragmentation. Note that this section should be changed somehow to accommodate responses at the UAS, besides requests at the proxy. 4) Although the table in section 6 specifies that the headers Proxy-Max-Size and Proxy-Seen-Size applies to 513 responses, it does not say to which request the response applies (there are "-" in all the columns, and should be "o". Suggestion: Header field where proxy ACK BYE CAN INV OPT REG ____________________________________________________________ Proxy-Max-Size 513 a o o o o o o Proxy-Seen-Size 513 a o o o o o o Header field SUB NOT PRA INF UPD MSG REF _______________________________________________________________ Proxy-Max-Size 513 o o o o o o o Proxy-Seen-Size 513 o o o o o o o Regards, Miguel Dean Willis wrote: > > Based on list feedback and AD directions the SIP transport congestion > safety draft has been revised and resubmitted under a WG title to the > archives and should appear shortly. In the interimn, you may wish to > review: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.html > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.xml > > I'd like to ask you to consider the relation to: > > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe > -ci-00.txt > > Specifically, these seem to refer to different aspects of congestion > safety. Is some sort of convergence needed? If so, what and how? > > Thanks, > > -- > Dean Willis > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 8 13:58:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21285 for ; Thu, 8 Aug 2002 13:58:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20108 for sip-archive@odin.ietf.org; Thu, 8 Aug 2002 13:59:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18860; Thu, 8 Aug 2002 13:31:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18811 for ; Thu, 8 Aug 2002 13:31:05 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20481 for ; Thu, 8 Aug 2002 13:29:51 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H0J00BFWCMLQI@firewall.wcom.com> for sip@ietf.org; Thu, 08 Aug 2002 17:30:22 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H0J00A01CIJM8@dgismtp01.wcomnet.com>; Thu, 08 Aug 2002 17:30:22 +0000 (GMT) Received: from hsinnreich2 ([166.44.56.54]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H0J0091NCLVFS@dgismtp01.wcomnet.com>; Thu, 08 Aug 2002 17:29:57 +0000 (GMT) Date: Thu, 08 Aug 2002 12:29:55 -0500 From: Henry Sinnreich Subject: RE: [Sip] Anybody knows how long SIP call setup takes? In-reply-to: <3D52242A.BA2CA977@alcatel.be> To: lieve.bos@alcatel.be, sip@ietf.org, sip-implementors@cs.columbia.edu Message-id: <000001c23f01$370f1e10$36382ca6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > 2) By how much does the call setup delay increase when the > SIP session is established using the "assured QoS" model You are aiming at the right problem IMHO: Adding up the call setup time using the "Assured QoS" model leads to very bad results, since SIP and such as RSVP setup gets closely coupled SIP and QoS setup and very complex. Actually, we have shown in some earlier work to have up to 50 messages (!) to establish such a session in an inter-domain environment. Please see http://www.softarmor.com/sipwg/drafts/morgue/draft-sinnreich-sip-qos-osp -01.txt I believe that emulating the PSTN with "Assured QoS" is fundamentally broken. What if the user would be just content to be alerted that no Qos is "assured", but would like to make the call anyway (maybe at lower cost or no cost)? Should an emergency call be refused because of lack of QoS? Waiting too long for QoS is no QoS at all... Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of lieve.bos@alcatel.be > Sent: Thursday, August 08, 2002 2:56 AM > To: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip] Anybody knows how long SIP call setup takes? > > > Hello, > > 1) Does anybody know how long a SIP call setup take? I am > particularly interested in the mobile case where there is for > each user a P-CSCF (proxy SIP server in visited network) and > S-CSCF (serving SIP server in home network) involved. > > 2) By how much does the call setup delay increase when the > SIP session is established using the "assured QoS" model > (i.e. when guarantee of end-to-end resource reservation is > required before ringing is started). In this case more SIP > messages (i.e. SIP 183, SIP UPDATE,...) are sent back and > forth before ringing actually takes place. > > 3) In the particular case of third party call control (SIP > application server setting up call between 2 endusers), does > anyone have figures on how long that takes (preferably again > in worst case - i.e. when using "assured QoS" model). > > 4) In all these cases getting the first INVITE through > probably takes the longest. After the signalling "path" has > been established between the two end hosts I guess the next > SIP messages (e.g. Ringing, ACK,...) take less time to pass > from one end to the other. Anyone any idea how long it takes > for such a SIP message to travel one way between two end hosts? > > Thanks for your help, > > Lieve Bos > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Fri Aug 9 06:21:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21596 for ; Fri, 9 Aug 2002 06:21:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16171 for sip-archive@odin.ietf.org; Fri, 9 Aug 2002 06:23:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14658; Fri, 9 Aug 2002 05:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14629 for ; Fri, 9 Aug 2002 05:49:12 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21043 for ; Fri, 9 Aug 2002 05:47:54 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g799gEm00958 for ; Fri, 9 Aug 2002 15:12:14 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C10.0035D6C0 ; Fri, 9 Aug 2002 15:18:03 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C10.0035D597.00@sampark.hss.hns.com> Date: Fri, 9 Aug 2002 15:18:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] comment on draft-ietf-sip-congestsafe-00: PMTU Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, The draft does not seem to explicitely address the situation of PMTU(Path MTU) changing. If it is supposed to be implicetely addressed by having a proxy return the current PMTU in "Proxy-Max-Size" header field in the 513 response, then the case of PMTU decreasing seems to be addressed. i.e, if the new PMTU(as discovered by the proxy) for a path is lower then the current PMTU, a new request destined for the same path will be responded with a 513 response with "Proxy-Max-Size" field having a lower value than the last. The UA will therefore get to know the new lower PMTU and may reject requests exceeding that limit. However for a case when the new PMTU is greater, there is no way, in the proposed mechanism, for the UA to know the new PMTU. One might argue that since the draft aims primarily at avoiding congestion, UA getting to know a greater PMTU does not contribute to congestion avoidance, but to improved utilization. However if the UA rejects requests based on the PMTU, then in this case, the UAC would be rejecting requests when may actually pass unfragmented due to an increase in the PMTU. So, at the least, a note should be added at the end of section 5.3 to state that the PMTU of the path in question may also increase and the proposed mechanism does not enable for the increase to be conveyed back to the UAC. regards Harsh Bhondwe Hughes Software Systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 9 10:21:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27994 for ; Fri, 9 Aug 2002 10:21:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28483 for sip-archive@odin.ietf.org; Fri, 9 Aug 2002 10:23:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26904; Fri, 9 Aug 2002 09:51:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26859 for ; Fri, 9 Aug 2002 09:51:41 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27283 for ; Fri, 9 Aug 2002 09:50:23 -0400 (EDT) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g79Di1m02493 for ; Fri, 9 Aug 2002 19:14:01 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C10.004BFA8A ; Fri, 9 Aug 2002 19:19:53 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C10.004BF8FD.00@sampark.hss.hns.com> Date: Fri, 9 Aug 2002 19:19:48 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] cc-transfer-05 : use of Call-IDs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a doubt regarding draft-ietf-cc-transfer-05.txt. The examples shown in sections 7.1-7.3 show the _same_ Call-ID being used by the new dialog created as part of the transfer. Is there some reasoning behind re-using the Call-ID for the new dialog ? I understand that the "call-leg" as such would be different due to the presence of a different "To" header (and hence To-tag), but using a new Call-ID:3 would make the examples more clear, IMHO. Please let me know if i am missing something... Regards, Subhash Nayak Hughes Software Systems http://www.hssworld.com This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 9 11:41:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00651 for ; Fri, 9 Aug 2002 11:41:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03003 for sip-archive@odin.ietf.org; Fri, 9 Aug 2002 11:42:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01383; Fri, 9 Aug 2002 11:14:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01352 for ; Fri, 9 Aug 2002 11:14:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29464 for ; Fri, 9 Aug 2002 11:13:05 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79FDmM01523 for ; Fri, 9 Aug 2002 11:13:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 11:13:49 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A79D@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'sip@ietf.org'" Date: Fri, 9 Aug 2002 11:13:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FB6.F91DC712" Subject: [Sip] Missing Phrase In RFC 3261 Sec. 23.2 (S/MIME)? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23FB6.F91DC712 Content-Type: text/plain; charset="iso-8859-1" Section 23.2 of RFC 3261 has this text: When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME [sic, no period] Later this text appears: When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. Should the UAC requirement have been the same as the UAS requirement? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C23FB6.F91DC712 Content-Type: text/html; charset="iso-8859-1" Missing Phrase In RFC 3261 Sec. 23.2 (S/MIME)?

Section 23.2 of RFC 3261 has this text:

When a UAC sends a request containing an S/MIME body that initiates a
   dialog, or sends a non-INVITE request outside the context of a
   dialog, the UAC SHOULD structure the body as an S/MIME [sic, no period]

Later this text appears:

When a UAS sends a response containing an S/MIME body that answers
   the first request in a dialog, or a response to a non-INVITE request
   outside the context of a dialog, the UAS SHOULD structure the body as
   an S/MIME 'multipart/signed' CMS SignedData body.

Should the UAC requirement have been the same as the UAS requirement?

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C23FB6.F91DC712-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 9 12:00:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01337 for ; Fri, 9 Aug 2002 12:00:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05009 for sip-archive@odin.ietf.org; Fri, 9 Aug 2002 12:01:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02877; Fri, 9 Aug 2002 11:37:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02844 for ; Fri, 9 Aug 2002 11:37:46 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00486 for ; Fri, 9 Aug 2002 11:36:28 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g79FbB311023; Fri, 9 Aug 2002 10:37:11 -0500 From: "Dean Willis" To: , Subject: RE: [Sip] comment on draft-ietf-sip-congestsafe-00: PMTU Date: Fri, 9 Aug 2002 10:36:40 -0500 Message-ID: <001401c23fba$8edeaca0$eb036e3f@TXDWILLIS2> 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.3416 Importance: Normal In-Reply-To: <65256C10.0035D597.00@sampark.hss.hns.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The draft does not seem to explicitely address the situation > of PMTU(Path > MTU) changing. If it is supposed to be implicetely addressed > by having a proxy return the current PMTU in "Proxy-Max-Size" > header field in the 513 response, then the case of PMTU > decreasing seems to be addressed. > > i.e, if the new PMTU(as discovered by the proxy) for a path > is lower then the current PMTU, a new request destined for > the same path will be responded with a 513 response with > "Proxy-Max-Size" field having a lower value than the last. > The UA will therefore get to know the new lower PMTU and may > reject requests exceeding that limit. However for a case when > the new PMTU is greater, there is no way, in the proposed > mechanism, for the UA to know the new PMTU. One might argue > that since the draft aims primarily at avoiding congestion, > UA getting to know a greater PMTU does not contribute to > congestion avoidance, but to improved utilization. However if > the UA rejects requests based on the PMTU, then in this case, > the UAC would be rejecting requests when may actually pass > unfragmented due to an increase in the PMTU. > Yeah. You're right (although the draft is about PROXIES rejecting requests, not UASs). If we go down this route, people are going to insist on reinventing every bit of the windowing protocol from TCP on top of SIP/UDP. I don't believe that's really acceptable. One alternative is to have a minimal mechanism that preserves congestion safety for the holdouts that insist on using UDP. That's what the authors were trying to do with this draft. Maybe it's not the right way to go? What if we just go ahead and deprecate UDP and everything to do with it from SIP? Migual Garcia (who is involved in 3G) has argued that since 3261 made TCP support mandatory (any compliant SIP node MUST support TCP), that deprecating UDP would be "backward compatible" with 3261. > So, at the least, a note should be added at the end of > section 5.3 to state that the PMTU of the path in question > may also increase and the proposed mechanism does not enable > for the increase to be conveyed back to the UAC. The previous seems like a reasonable suggestion for improving the existing draft, and I propose to incorporate it. -- 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 daemon@optimus.ietf.org Fri Aug 9 12:56:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03194 for ; Fri, 9 Aug 2002 12:56:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07981 for sip-archive@odin.ietf.org; Fri, 9 Aug 2002 12:57:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06311; Fri, 9 Aug 2002 12:29:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06244 for ; Fri, 9 Aug 2002 12:29:07 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02374 for ; Fri, 9 Aug 2002 12:27:52 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g79GT5M21738; Fri, 9 Aug 2002 12:29:05 -0400 (EDT) Reply-To: From: "Eric Burger" To: "Dean Willis" , Cc: Subject: RE: [Sip] SIP Congestion Safety Draft Revised Date: Fri, 9 Aug 2002 12:29:04 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D522D76.9134BC80@ericsson.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The idea that the response may be too big is interesting and will take some thought. I was wondering if there is *any* sensible error mechanism. Consider the following: UA -------> Proxy A -------> Proxy B -------> XXX small moderate too big, msg msg send back The UA sends a small message. Proxy A forwards it, maybe adding a VIA and other stuff. Proxy B tries to forward the message, but by adding its VIA's etc. the message is too big. Proxy B would then fail the request, setting Proxy-Max-Size to less than Proxy-Seen-Size. The problem is that Proxy-Seen-Size is much larger than what the UA sent, and most likely larger than what Proxy A sent. The point is the growth of the message is beyond the control of the device getting the error message. Moreover, what is the poor human at the UA supposed to do? True, if the error occurs because the user is sending a large IM, then they know they shouldn't do that. However, if the error occurs because of VIA growing or other proxy-inserted headers, then the problem is entirely beyond the control of the user and probably beyond their comprehension. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Miguel A. Garcia Sent: Thursday, August 08, 2002 4:36 AM To: Dean Willis; bcampbell@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] SIP Congestion Safety Draft Revised I have been reading this draft, and I have some questions and comments. 1) In section 4 I found this sentence: Proxies not recognizing a specific tag or unwilling to support the associated behavior MUST reject a request referencing that tag with a 420 response, which has the semantic "Unsupported". Although I agree with the technical contents, I believe that the normative text (proxy MUST return a 420 response with Unsupported header) is already covered in RFC 3261. I think is simply better not to specify the same procedure, and just refer to the actions described in RFC 3261. 2) Section 5 states: "Clearly the best thing to do is to use a more sophisticated transport protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and its associated proxy. If this is not feasible, it may be necessary to fall back to UDP. This is especially common in the case of low- capacity UAs such as those proposed for 3G wireless systems." I disagree with the example of the last sentence. I have been working for a while with the 3GPP standardization, and there is no reference to an exclusive usage of UDP in either terminals or proxies. As a background information, 3GPP TS 24.229 defines the SIP profile used by 3GPP. This specification "imports" RFC 3261 and a number of other RFCs. This means, that unless some optionality in RFC 3261 is made mandatory in 24.229, the text in RFC 3261 applies. Currently, there is not mention at all to the transport protocols in 24.229. This means that the text in RFC 3261 is applicable as it is. RFC 3261 says in section 18: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Conclusion: in 3GPP all the terminals and proxies MUST implement TCP and UDP, although they can implement other transport protocols. Now, coming back to the draft, I don't see the point of having such a long discussion about UAs that can't use TCP, because the case does not exist. If a devices is RFC 3261 compliant, it MUST implement TCP. 3) The last paragraph in section 5.1 reveals what I consider is an important problem: routing of SIP responses must follow the Via header, and that includes the transport protocol to the receiver of the request. This is a big problem, because a UA may send a short SIP request, that fits in a UDP packet, but the response may be significantly large, and it does not fit in there. It could be interesting to have a procedures to do either of these actions: a) The UA could signal in the Via header the set of transport protocols supported, so that the proxy which forwards the response could freely choose another protocol, if deemed. b) The UAS could use the procedures in section 5.3, Proxy Rejects Request That Would Require UDP Fragmentation. Note that this section should be changed somehow to accommodate responses at the UAS, besides requests at the proxy. 4) Although the table in section 6 specifies that the headers Proxy-Max-Size and Proxy-Seen-Size applies to 513 responses, it does not say to which request the response applies (there are "-" in all the columns, and should be "o". Suggestion: Header field where proxy ACK BYE CAN INV OPT REG ____________________________________________________________ Proxy-Max-Size 513 a o o o o o o Proxy-Seen-Size 513 a o o o o o o Header field SUB NOT PRA INF UPD MSG REF _______________________________________________________________ Proxy-Max-Size 513 o o o o o o o Proxy-Seen-Size 513 o o o o o o o Regards, Miguel Dean Willis wrote: > > Based on list feedback and AD directions the SIP transport congestion > safety draft has been revised and resubmitted under a WG title to the > archives and should appear shortly. In the interimn, you may wish to > review: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.html > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.xml > > I'd like to ask you to consider the relation to: > > http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe > -ci-00.txt > > Specifically, these seem to refer to different aspects of congestion > safety. Is some sort of convergence needed? If so, what and how? > > Thanks, > > -- > Dean Willis > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 daemon@optimus.ietf.org Fri Aug 9 14:40:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06766 for ; Fri, 9 Aug 2002 14:40:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14433 for sip-archive@odin.ietf.org; Fri, 9 Aug 2002 14:42:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12844; Fri, 9 Aug 2002 14:14:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12812 for ; Fri, 9 Aug 2002 14:13:57 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05901 for ; Fri, 9 Aug 2002 14:12:43 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g79IDvM23324 for ; Fri, 9 Aug 2002 14:13:57 -0400 (EDT) Reply-To: From: "Eric Burger" To: Subject: RE: [Sip] The cost of UDP Date: Fri, 9 Aug 2002 14:13:56 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just in case one was thinking "how often does a power failure occur in a city -- it is a corner case I can ignore"... Consider a conference bridge w/ 80,000 ports. Most conferences start on the hour, with people connecting in a 3 minute window. Not only is that more than 64,000 connections, but that corresponds to a connection rate of over 1,000,000 connections per hour. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Cullen Jennings Sent: Tuesday, July 16, 2002 8:56 PM To: sip@ietf.org Cc: 'Avshalom Houri'; Dean Willis Subject: RE: [Sip] The cost of UDP Few thoughts on this .... 64,000 subscriber per host is not very many - people that are going to deploy millions of users don't want a boat load of servers to manage. 64,000 could correspond to around 50 cps. I can imagine proxies that easily do 500 cps on a cheap machine today and I can imagine proxies that do 30,000 cps on a $1000 machine 10 years from now. Perhaps no one will care about that level of performance but the point I am making is simple - 64,000 users per host is very low. If a host supported several IP address on a single interface, it might be able to do more than 64k TCP connections. Should work in theory but probably does not work in practice. The following scenario is quite realistic - We end up with a city with several million IP phones. This city regularly looses power resulting in all UA simultaneously rebooting and trying to register. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 12 08:36:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19054 for ; Mon, 12 Aug 2002 08:36:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07513 for sip-archive@odin.ietf.org; Mon, 12 Aug 2002 08:37:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06467; Mon, 12 Aug 2002 08:17:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06438 for ; Mon, 12 Aug 2002 08:17:24 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18254 for ; Mon, 12 Aug 2002 08:16:05 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7CCH3Rb001177; Mon, 12 Aug 2002 14:17:03 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7CCGra9007975; Mon, 12 Aug 2002 15:16:53 +0300 (EET DST) Message-ID: <3D57A733.51335596@lmf.ericsson.se> Date: Mon, 12 Aug 2002 15:16:51 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip CC: Jon Peterson , Allison Mankin , Dean Willis , Biran Rosen , Rohan Mahy , Adam Roach References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Final version of the overlap draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I have just submitted the 03 version of the overlap draft. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-ietf-sipping-overlap-03.txt The diffs from previous versions are: We have removed references to the COMET method (it does not exist anymore). Previous versions said that dialogs were identified by, among other things, the whole To header field. Since now we only use tags, the text has been fixed. The draft does not define the 490 Request Updated status code anymore. Since at last, this was the only draft using that status code, we do not want to define a new status code for a mechanism (i.e., overlapping) that is NOT RECOMMENDED. We mention that native SIP user agents must not generate overlapped signalling but that overlapped SIP signalling might land on a native SIP user agent. In section 3.4 we reduced the strength of the requirements for an ingress gateway. Now it reads as follows: "Therefore, overlap signaling cannot be used when attempting to reach parts of the PSTN where it is possible for a number and some shorter prefix of the same number to both be valid addresses of different terminals. " Note that the IETF last call for this draft finished August 5th. Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 12 19:50:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14971 for ; Mon, 12 Aug 2002 19:50:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17926 for sip-archive@odin.ietf.org; Mon, 12 Aug 2002 19:51:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17370; Mon, 12 Aug 2002 19:34:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17341 for ; Mon, 12 Aug 2002 19:34:30 -0400 (EDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14623 for ; Mon, 12 Aug 2002 19:33:11 -0400 (EDT) Received: from aslan ([12.224.107.17]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020812233358.HSHW19356.rwcrmhc51.attbi.com@aslan>; Mon, 12 Aug 2002 23:33:58 +0000 Reply-To: From: "Jack W. Lix" To: "Ben Campbell" , , , Date: Mon, 12 Aug 2002 16:36:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] CPIM draft referenced in draft-ietf-sip-message-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, draft-ietf-sip-message-06.txt references an expired draft in reference [3], draft-ietf-impp-cpim-02. The text refers to this doc as containing the address resolution rules. My research shows this draft is expired and unavailable. 1) Where can I get this draft (or does something replace it)? 2) Why don't the SIP PROXY rules determine the next hop? TIA, Jack Jack W. Lix Jack.Lix@windriver.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 daemon@optimus.ietf.org Tue Aug 13 12:17:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18508 for ; Tue, 13 Aug 2002 12:17:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20744 for sip-archive@odin.ietf.org; Tue, 13 Aug 2002 12:19:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17702; Tue, 13 Aug 2002 11:39:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17670 for ; Tue, 13 Aug 2002 11:39:40 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16793 for ; Tue, 13 Aug 2002 11:38:21 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g7DFdSpA021952; Tue, 13 Aug 2002 10:39:29 -0500 (CDT) Message-ID: <3D5927D0.2040408@dynamicsoft.com> Date: Tue, 13 Aug 2002 10:37:52 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JackLix@attbi.com CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org References: X-Enigmail-Version: 0.61.1.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 Subject: [Sip] Re: CPIM draft referenced in draft-ietf-sip-message-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit For now you can get it at http://www.brandenburg.com/specifications/draft-ietf-impp-cpim-02.txt Hopefully there will be a new version soon. That draft contains rules for address resolution of "pres" and "im" URLs. Resolution of SIP URIs follow normal SIP resolution rules. Jack W. Lix wrote: > Hi, > > draft-ietf-sip-message-06.txt references an expired draft in reference [3], > draft-ietf-impp-cpim-02. The text refers to this doc as containing the > address resolution rules. > > My research shows this draft is expired and unavailable. > > 1) Where can I get this draft (or does something replace it)? > > 2) Why don't the SIP PROXY rules determine the next hop? > > TIA, > > Jack > Jack W. Lix > Jack.Lix@windriver.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 daemon@optimus.ietf.org Tue Aug 13 23:24:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01439 for ; Tue, 13 Aug 2002 23:24:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05611 for sip-archive@odin.ietf.org; Tue, 13 Aug 2002 23:25:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04043; Tue, 13 Aug 2002 22:57:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04015 for ; Tue, 13 Aug 2002 22:57:52 -0400 (EDT) Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00716 for ; Tue, 13 Aug 2002 22:56:31 -0400 (EDT) Message-Id: <200208140256.WAA00716@ietf.org> Received: (qmail 2692 invoked from network); 14 Aug 2002 03:14:38 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 14 Aug 2002 03:14:38 -0000 Date: Wed, 14 Aug 2002 11:4:14 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org." Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA04016 Subject: [Sip] Content-Indirection Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi All, In draft-khartabil-sip-congestionsafe-ci-00.txt , it mentions "Content-Indirection", and I want to know what is "Content-Indirection"? Where is the definition? Thanks a lot! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 14 00:49:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03598 for ; Wed, 14 Aug 2002 00:49:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA09608 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 00:50:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07817; Wed, 14 Aug 2002 00:17:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07792 for ; Wed, 14 Aug 2002 00:16:59 -0400 (EDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02648 for ; Wed, 14 Aug 2002 00:15:38 -0400 (EDT) Received: from 12-235-146-159.client.attbi.com (HELO BOB) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Aug 2002 04:16:57 -0000 Reply-To: From: "Sean Olson" To: , Subject: RE: [Sip] Content-Indirection Date: Tue, 13 Aug 2002 21:17:11 -0700 Message-ID: <000d01c24349$771a6f90$6401a8c0@BOB> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 In-Reply-To: <200208140256.WAA00716@ietf.org> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You may wish to read the following drafts: http://search.ietf.org/internet-drafts/draft-olson-sip-content-indirect- mech-01.txt http://search.ietf.org/internet-drafts/draft-ietf-sipping-content-indire ct-01.txt In a nutshell, content indirection simply means including a URL in a SIP message which refers to some content you wish the receiving party to access. Rather than carrying this content in the body of the SIP message, the URL points to this content. Typically this is done because the content is too large to carry directly in the SIP message. Hope this helps, Sean Olson Microsoft -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of feng zhang Sent: Tuesday, August 13, 2002 8:00 PM To: sip@ietf.org. Subject: [Sip] Content-Indirection Hi All, In draft-khartabil-sip-congestionsafe-ci-00.txt , it mentions "Content-Indirection", and I want to know what is "Content-Indirection"? Where is the definition? Thanks a lot! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 daemon@optimus.ietf.org Wed Aug 14 02:29:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28080 for ; Wed, 14 Aug 2002 02:29:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06129 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 02:30:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21396; Wed, 14 Aug 2002 01:57:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21365 for ; Wed, 14 Aug 2002 01:57:46 -0400 (EDT) Received: from jopasana.com ([128.121.218.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04663 for ; Wed, 14 Aug 2002 01:56:26 -0400 (EDT) Received: from spp.jopasana.com ([203.197.90.74]) by jopasana.com (8.11.6) id g7E5vgS08098; Tue, 13 Aug 2002 23:57:43 -0600 (MDT) Message-Id: <5.1.0.14.0.20020814112753.00a6f710@jopasana.com> X-Sender: smita@jopasana.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Aug 2002 11:29:20 +0530 To: sip@ietf.org From: Smita In-Reply-To: <200208131600.MAA18708@optimus.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Please Un subscribe me Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Please un subscribe me from your mailing list. Thanks, smita _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 14 04:35:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00601 for ; Wed, 14 Aug 2002 04:35:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12553 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 04:36:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10893; Wed, 14 Aug 2002 04:15:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10862 for ; Wed, 14 Aug 2002 04:14:59 -0400 (EDT) Received: from mta1 ([61.144.161.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00100 for ; Wed, 14 Aug 2002 04:13:37 -0400 (EDT) Received: from PRASANNA (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H0T00I3JQUJJJ@mta1.huawei.com> for sip@ietf.org; Wed, 14 Aug 2002 16:13:32 +0800 (CST) Date: Wed, 14 Aug 2002 16:17:21 +0800 From: Prasanna In-reply-to: <200208121600.MAA19172@optimus.ietf.org> To: sip@ietf.org Cc: chengzhengqun@huawei.com, li_wen@huawei.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Subject: [Sip] How to respond if the request has no Call-ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, According to RFC 3261 section 21.4.1 "The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field"." If a request comes without a Call-ID header field, what call-ID should the 400 response bear. The same issue is applicable for "To" "From" CSeq" headers also. Another issue is, if a request does not bear a "Via" header, where should the response go, if at all the UAS decides to respond. Thanks in advance for the responses, Regards, Prasanna _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 14 10:25:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10523 for ; Wed, 14 Aug 2002 10:25:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01759 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 10:27:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01170; Wed, 14 Aug 2002 10:03:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01139 for ; Wed, 14 Aug 2002 10:03:08 -0400 (EDT) Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09495 for ; Wed, 14 Aug 2002 10:01:45 -0400 (EDT) Message-Id: <200208141401.KAA09495@ietf.org> Received: (qmail 13348 invoked from network); 14 Aug 2002 14:19:55 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 14 Aug 2002 14:19:55 -0000 Date: Wed, 14 Aug 2002 22:9:31 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "Sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id KAA01140 Subject: [Sip] Does this exist? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi All, I read draft-olson-sip-content-indirect-mech-01.txt, and I want to know is there draft-olson-sip-content-indirect-mech-00.txt? if it exists, then what's the relationship of the two drafts? In draft-olson-sip-content-indirect-mech-01.txt , I do not find any "Changes" statements. Best Regard. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 14 10:34:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10991 for ; Wed, 14 Aug 2002 10:34:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02609 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 10:35:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01507; Wed, 14 Aug 2002 10:15:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01472 for ; Wed, 14 Aug 2002 10:15:46 -0400 (EDT) Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10083 for ; Wed, 14 Aug 2002 10:14:25 -0400 (EDT) Message-Id: <200208141414.KAA10083@ietf.org> Received: (qmail 13611 invoked from network); 14 Aug 2002 14:32:35 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 14 Aug 2002 14:32:35 -0000 Date: Wed, 14 Aug 2002 22:22:11 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id KAA01473 Subject: [Sip] Does this exist? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi All, I read draft-olson-sip-content-indirect-mech-01.txt, and I want to know is there draft-olson-sip-content-indirect-mech-00.txt? if it exists, then what's the relationship of the two drafts? In draft-olson-sip-content-indirect-mech-01.txt , I do not find any "Changes" statements. Best Regard. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Aug 14 11:46:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14058 for ; Wed, 14 Aug 2002 11:46:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07150 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 11:48:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05175; Wed, 14 Aug 2002 11:16:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05144 for ; Wed, 14 Aug 2002 11:16:47 -0400 (EDT) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13075 for ; Wed, 14 Aug 2002 11:15:25 -0400 (EDT) Received: from 12-235-146-159.client.attbi.com (HELO BOB) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Aug 2002 15:16:44 -0000 Reply-To: From: "Sean Olson" To: , Subject: RE: [Sip] Does this exist? Date: Wed, 14 Aug 2002 08:16:57 -0700 Message-ID: <003e01c243a5$a2391530$6401a8c0@BOB> 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.3416 In-Reply-To: <200208141401.KAA09495@ietf.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The delta between the two documents was not significant enough to warrant a Changes section. I made support for http: URLs mandatory and I added some text on S/MIME. The -01 version replaces the -00 version which is no longer available. /sean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of feng zhang Sent: Wednesday, August 14, 2002 7:01 AM To: Sip@ietf.org Subject: [Sip] Does this exist? Hi All, I read draft-olson-sip-content-indirect-mech-01.txt, and I want to know is there draft-olson-sip-content-indirect-mech-00.txt? if it exists, then what's the relationship of the two drafts? In draft-olson-sip-content-indirect-mech-01.txt , I do not find any "Changes" statements. Best Regard. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 daemon@optimus.ietf.org Wed Aug 14 14:38:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20797 for ; Wed, 14 Aug 2002 14:38:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17702 for sip-archive@odin.ietf.org; Wed, 14 Aug 2002 14:40:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16268; Wed, 14 Aug 2002 14:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16239 for ; Wed, 14 Aug 2002 14:17:42 -0400 (EDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19879 for ; Wed, 14 Aug 2002 14:16:22 -0400 (EDT) Received: from aslan ([12.224.107.17]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020814181710.JQRJ19356.rwcrmhc51.attbi.com@aslan>; Wed, 14 Aug 2002 18:17:10 +0000 Reply-To: From: "Jack W. Lix" To: Cc: "Ben Campbell" Date: Wed, 14 Aug 2002 11:19:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3D5927D0.2040408@dynamicsoft.com> Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-message-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A few comments/nits on the draft: NIT: section 4, the second paragraph starts "All UAs" - this should be changed to "All UAC's to avoid confusion between UAs/UAS and to hilight that a UAC MUST receive/decode cpim when a UAS MAY send them. COMMENT: Why force a UAC to handle CPIM? Frankly, I don't have it coded (but I do have MIME coded) and don't understand it's importance (so, you get to educate me here!). NIT: section 9, paragraph 7: "The prohibition againt" s/b against NIT: section 12.4, 1st paragraph, 2nd sentence, "should be answered" s/b "SHOULD be answered" Finally, I don't quite understand the Record-Route issue. If I send a IM-URI to an outbound proxy and it, perhaps unaware of IM issues, adds a Record-Route, won't my address be in the Record-Route with an IM address? Doesn't the change to loose routing move the TO field into the Record-Route field? I know I Thanks for the help, Jack Jack W. Lix _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 15 06:25:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19854 for ; Thu, 15 Aug 2002 06:25:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA18636 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 06:26:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17756; Thu, 15 Aug 2002 06:11:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17720 for ; Thu, 15 Aug 2002 06:11:11 -0400 (EDT) Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19576 for ; Thu, 15 Aug 2002 06:09:49 -0400 (EDT) Message-Id: <200208151009.GAA19576@ietf.org> Received: (qmail 30921 invoked from network); 15 Aug 2002 10:28:06 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 15 Aug 2002 10:28:06 -0000 Date: Thu, 15 Aug 2002 18:17:44 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA17724 Subject: [Sip] 3-way conference Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi All, I want to fulfill "3-way Conference" in this way : User A------------User B \ / \ / \ / \ / <------------------- RTP channels \ / \ / \ / User C Notes: 1) User A, User B, User C want to "3-way Conference" 2) Every user should setup two RTP channels with the other two users, for examples, User A should setup a RTP channel with User B , and should setup a RTP channel with User C, thus , User A's Voice can be sent to B & C, on the other hand, User B & C 's voice can be received separately on two RTP channels, and User A can hear B & C's voice simultaneously. In this way, I can fulfill "3-way Conference". But I want to know : 1) look at the scenario below: User A User B User C | INVITE | | |------------------>| | | | | | INVITE | |--------------------------------------->| | | How User B INVITE User C , AND let User C know this INVITE is for the same session(3-way Conference) ? 2) in RFC3261 section "13.3.1 Processing of the INVITE" it says: "The INVITE may contain a session description, in which case the UAS is being presented with an offer for that session. It is possible that the user is already a participant in that session, even though the INVITE is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple other ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ participants. If desired, the UAS MAY use identifiers within the session description to detect this duplication. For example, SDP contains a session id and version number in the origin (o) field. " I want to know whether "the same multicast conference by multiple other participants" it mentions is the way to fulfill a service like "3-way conference"? Thank you! Best Regard! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 15 08:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21510 for ; Thu, 15 Aug 2002 08:04:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24635 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 08:05:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23257; Thu, 15 Aug 2002 07:49:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23226 for ; Thu, 15 Aug 2002 07:49:06 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21069 for ; Thu, 15 Aug 2002 07:47:43 -0400 (EDT) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g7FBmuS23193; Thu, 15 Aug 2002 13:48:56 +0200 (MEST) Message-ID: <3D5B95BA.2010808@tzi.uni-bremen.de> Date: Thu, 15 Aug 2002 13:51:22 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Slides from Session #2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit May I ask all presenters of the second SIP session in Yokohama to send me a copy of their slides. We have everything for the first one but quite a bit seems to be missing for the second. Thanks a lot, Joerg _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 15 08:32:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22785 for ; Thu, 15 Aug 2002 08:32:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26576 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 08:33:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24489; Thu, 15 Aug 2002 08:04:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24460 for ; Thu, 15 Aug 2002 08:04:13 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21390 for ; Thu, 15 Aug 2002 08:02:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7FC6YW00319 for ; Thu, 15 Aug 2002 15:06:34 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Aug 2002 13:22:50 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 13:22:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: RE: [Sip] 3-way conference Date: Thu, 15 Aug 2002 13:22:49 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2049E@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] 3-way conference Thread-Index: AcJERC9t2NfbkGJNTgGluhFIOr5kaAAAIXww To: , X-OriginalArrivalTime: 15 Aug 2002 10:22:49.0965 (UTC) FILETIME=[B4FC21D0:01C24445] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA24461 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Please take a look at http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-06.txt and http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-models-01.txt Regards, Hisham > -----Original Message----- > From: ext feng zhang [mailto:y01317@njupt.edu.cn] > Sent: Thursday, August 15, 2002 1:18 PM > To: sip@ietf.org > Subject: [Sip] 3-way conference > > > Hi All, > > I want to fulfill "3-way Conference" in this way : > > User A------------User B > \ / > \ / > \ / > \ / <------------------- RTP channels > \ / > \ / > \ / > User C > > Notes: 1) User A, User B, User C want to "3-way Conference" > 2) Every user should setup two RTP channels with > the other two users, > for examples, User A should setup a RTP channel > with User B , and should > setup a RTP channel with User C, thus , User A's > Voice can be sent to B & C, > on the other hand, User B & C 's voice can be > received separately on two > RTP channels, and User A can hear B & C's voice > simultaneously. In this way, > I can fulfill "3-way Conference". > > But I want to know : > 1) look at the scenario below: > > User A User B User C > | INVITE | | > |------------------>| | > | | | > | INVITE | > |--------------------------------------->| > | | > How User B INVITE User C , AND let User C know this > INVITE is for the same > session(3-way Conference) ? > > 2) in RFC3261 section "13.3.1 Processing of the INVITE" > > it says: > > "The INVITE may contain a session description, in > which case the UAS > is being presented with an offer for that session. It is possible > that the user is already a participant in that session, even though > the INVITE is outside of a dialog. This can happen when a user is > invited to the same multicast conference by multiple other > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > participants. If desired, the UAS MAY use identifiers within the > session description to detect this duplication. For example, SDP > contains a session id and version number in the origin (o) > field. " > > I want to know whether "the same multicast conference > by multiple other > participants" it mentions is the way to fulfill a service > like "3-way conference"? > > Thank you! > > Best Regard! > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Thu Aug 15 08:44:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23364 for ; Thu, 15 Aug 2002 08:44:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26926 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 08:45:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25141; Thu, 15 Aug 2002 08:17:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25115 for ; Thu, 15 Aug 2002 08:17:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22019; Thu, 15 Aug 2002 08:16:01 -0400 (EDT) Message-Id: <200208151216.IAA22019@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 Aug 2002 08:16:01 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-content-indirect-mech-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Mechanism for Content Indirection in SIP Messages Author(s) : S. Olson Filename : draft-ietf-sip-content-indirect-mech-00.txt Pages : 13 Date : 14-Aug-02 This Internet-Draft proposes an extension to the URL MIME External- Body Access-Type as defined in RFC2017 [7] to satisfy the content indirection requirements defined in draft-ietf-sipping-content- indirect-01 [1]. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URL [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-00.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-content-indirect-mech-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020814134956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-content-indirect-mech-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020814134956.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 daemon@optimus.ietf.org Thu Aug 15 12:31:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03849 for ; Thu, 15 Aug 2002 12:31:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13636 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 12:33:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12712; Thu, 15 Aug 2002 12:18:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12683 for ; Thu, 15 Aug 2002 12:18:29 -0400 (EDT) Received: from tnint11.telogy.design.ti.com ([209.116.120.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03201 for ; Thu, 15 Aug 2002 12:17:08 -0400 (EDT) Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 12:17:52 -0400 Message-ID: <37A3C2F21006D611995100B0D0F9B73C028BD1@tnint11.telogy.design.ti.com> From: "Yadavalli, Satyamurthy" To: sip@ietf.org, sip-implementors@cs.columbia.edu Date: Thu, 15 Aug 2002 12:17:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="GB2312" Subject: [Sip] sip version Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The new SIP RFC-3261 specifies the SIP protocol version to be used as SIP/2. 0. So was it with the obsoleted RFC 2543. How do SIP entities distinguish between these implementations? Thanks, Satya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 15 12:46:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04344 for ; Thu, 15 Aug 2002 12:46:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14071 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 12:47:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05995; Thu, 15 Aug 2002 11:26:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05963 for ; Thu, 15 Aug 2002 11:26:20 -0400 (EDT) Received: from brixcorp2.brixnet.com ([63.122.27.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00511 for ; Thu, 15 Aug 2002 11:25:00 -0400 (EDT) Received: by mail.brixnet.com with Internet Mail Service (5.5.2656.59) id ; Thu, 15 Aug 2002 11:25:50 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB01943FB6@mail.brixnet.com> From: "Pyrik, Dan" To: "'sip@ietf.org'" Cc: "Hedayat, Kaynam" , "Naylor, Bob" , "Venna, Nagarjuna" Date: Thu, 15 Aug 2002 11:25:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP Traceroute using Max-Forwards Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I am trying to write an application that performs a "SIP Traceroute" by constantly incrementing the Max-Forwards header starting at 0. The SIP spec states: "The Max-Forwards request-header field may be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. ". However, I do not see how to figure out the IP address of any proxy other than the first outbound proxy. When any other proxy responds with a 483 Too Many Hops packet, it will forward its response along down the proxy chain and the client will receive the response packet with the IP source address set to the first outbound proxy. There is nothing within the SIP packet to show who the originator of the response packet is (without using Record Route headers). Is there any way to get this to work? Thanks, Dan Pyrik Brix Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Aug 15 19:42:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20176 for ; Thu, 15 Aug 2002 19:42:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18341 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 19:44:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17005; Thu, 15 Aug 2002 19:26:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16975 for ; Thu, 15 Aug 2002 19:26:05 -0400 (EDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19875 for ; Thu, 15 Aug 2002 19:24:45 -0400 (EDT) Received: from aslan ([12.224.107.17]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020815232527.MBOW1746.rwcrmhc51.attbi.com@aslan>; Thu, 15 Aug 2002 23:25:27 +0000 Reply-To: From: "Jack W. Lix" To: Cc: Subject: RE: [Sip] draft-ietf-sip-message-06 NIT Date: Thu, 15 Aug 2002 16:27:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Not sure if this belongs here or on sipping or simple list. Please advise. Section 3, 1st paragraph, 2nd sentence IS: but if may be SHOULD BE: but it may be Cheers, Jack Jack W. Lix WindRiver Systems, INC Jack.Lix@windriver.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 daemon@optimus.ietf.org Thu Aug 15 19:57:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20527 for ; Thu, 15 Aug 2002 19:57:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18835 for sip-archive@odin.ietf.org; Thu, 15 Aug 2002 19:59:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18039; Thu, 15 Aug 2002 19:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18010 for ; Thu, 15 Aug 2002 19:39:28 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20082 for ; Thu, 15 Aug 2002 19:38:07 -0400 (EDT) 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 g7FNbKc10153 for ; Thu, 15 Aug 2002 19:37:20 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g7FNbKs10148 for ; Thu, 15 Aug 2002 19:37:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: RE: [Sip] 3-way conference Date: Thu, 15 Aug 2002 17:39:27 -0600 Message-ID: Thread-Topic: [Sip] 3-way conference Thread-Index: AcJERDppRv7BhY/dSPCWmCU+yHhWJgAbjdvQ From: "Zmolek, Andrew (Andy)" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA18011 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Although the conferencing-models draft gives this approach as one example, SIP doesn't yet have a method for explicitly associating dialogs and media for a conference in this style. But ongoing work by the conferencing design team should provide at least a partial solution that would allow the two dialogs to become associated (i.e. conference ID) In your example below, you ask how User B can be told to invite User C. One approach would be to have User A send the B->C invite via 3rd Party Call Control mechanisms. Yes, there are multicast scenarios for a 3-way conference as well, but it seems unlikely that many UAs would support this. --Andy > -----Original Message----- > From: feng zhang [mailto:y01317@njupt.edu.cn] > Sent: Thursday, August 15, 2002 4:18 AM > To: sip@ietf.org > Subject: [Sip] 3-way conference > > > Hi All, > > I want to fulfill "3-way Conference" in this way : > > User A------------User B > \ / > \ / > \ / > \ / <------------------- RTP channels > \ / > \ / > \ / > User C > > Notes: 1) User A, User B, User C want to "3-way Conference" > 2) Every user should setup two RTP channels with > the other two users, > for examples, User A should setup a RTP channel > with User B , and should > setup a RTP channel with User C, thus , User A's > Voice can be sent to B & C, > on the other hand, User B & C 's voice can be > received separately on two > RTP channels, and User A can hear B & C's voice > simultaneously. In this way, > I can fulfill "3-way Conference". > > But I want to know : > 1) look at the scenario below: > > User A User B User C > | INVITE | | > |------------------>| | > | | | > | INVITE | > |--------------------------------------->| > | | > How User B INVITE User C , AND let User C know this > INVITE is for the same > session(3-way Conference) ? > > 2) in RFC3261 section "13.3.1 Processing of the INVITE" > > it says: > > "The INVITE may contain a session description, in > which case the UAS > is being presented with an offer for that session. It is possible > that the user is already a participant in that session, even though > the INVITE is outside of a dialog. This can happen when a user is > invited to the same multicast conference by multiple other > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > participants. If desired, the UAS MAY use identifiers within the > session description to detect this duplication. For example, SDP > contains a session id and version number in the origin (o) > field. " > > I want to know whether "the same multicast conference > by multiple other > participants" it mentions is the way to fulfill a service > like "3-way conference"? > > Thank you! > > Best Regard! > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Fri Aug 16 05:42:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09892 for ; Fri, 16 Aug 2002 05:42:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21421 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 05:43:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20448; Fri, 16 Aug 2002 05:20:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20419 for ; Fri, 16 Aug 2002 05:20:24 -0400 (EDT) Received: from bugs.cs.nthu.edu.tw (bugs.cs.nthu.edu.tw [140.114.79.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09620 for ; Fri, 16 Aug 2002 05:19:02 -0400 (EDT) Received: from localhost (utero@localhost) by bugs.cs.nthu.edu.tw (8.11.6/8.11.6) with ESMTP id g7H1bOj12245 for ; Sat, 17 Aug 2002 09:37:24 +0800 Date: Sat, 17 Aug 2002 09:37:24 +0800 (CST) From: Anthony Liu To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] SIP Server Roaming Problem Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, folks, I'm new here. If this problem has been discussed, please let me know. If not, I'm interested in this problem and would like to compose a new SIP extension draft or been added to some already existed draft. Here is a brief introduction: In mobile IP environments, mobile nodes (MN) move around and contacts their SIP server in home or foreign network. I'm not sure whether a MN will contact a SIP server in foreign network or the one in its home network. Can anyone tell me the answer? If this MN happens to move into a foreign network that wishes any MN in it contacting its SIP server instead of the one in home network, do we have a mechanism for this? I am not trying to address mobility problems which are handled by Mobile IP. The truth is I think in this way, a foreign network can do statistics about SIP sessions in its subnet or even diffserving SIP session packets from ordinary packets. Regards, Anthony Liu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 16 08:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12984 for ; Fri, 16 Aug 2002 08:20:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28547 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 08:21:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27459; Fri, 16 Aug 2002 07:55:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27428 for ; Fri, 16 Aug 2002 07:55:33 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12388 for ; Fri, 16 Aug 2002 07:54:10 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17ffhR-0002Fm-00; Fri, 16 Aug 2002 14:55:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15708.59441.377218.613090@harjus.eng.song.fi> Date: Fri, 16 Aug 2002 14:55:29 +0300 To: Anthony Liu Cc: sip@ietf.org Subject: [Sip] SIP Server Roaming Problem In-Reply-To: References: X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Anthony Liu writes: > If this MN happens to move into a foreign network that wishes any > MN in it contacting its SIP server instead of the one in home network, > do we have a mechanism for this? if you talk about MN that uses the 3g system, then there is no choice whatsoever. the MN is in the walled garden as defined by the guardians of the garden. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 16 08:26:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13164 for ; Fri, 16 Aug 2002 08:26:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28656 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 08:28:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28442; Fri, 16 Aug 2002 08:13:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28411 for ; Fri, 16 Aug 2002 08:13:47 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12837 for ; Fri, 16 Aug 2002 08:12:24 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 16 Aug 2002 14:13:15 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 14:13:14 +0200 Message-Id: From: "Jesske, R" To: dpyrik@Brixnet.com, sip@ietf.org Cc: khedayat@Brixnet.com, bnaylor@Brixnet.com, nvenna@Brixnet.com Subject: AW: [Sip] SIP Traceroute using Max-Forwards Date: Fri, 16 Aug 2002 14:13:11 +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 optimus.ietf.org id IAA28412 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello Dan and all From my understanding the Max Forward header is used for decrementing a value to avoid circular routing. Also there is a proposal within ITU for the SIP-ISUP mapping to map the Hop-Counter to the Max-Forward Header and vice versa to avoid circular routing. Therefore I think it is not a good idea to use the Max Forward for incrementing a value. Because if one domain increments the Max Forward Header and the other decrement it, you will never have a mechanism that avoids circular routing. Please correct me if I misunderstood your mail. Best regards Roland Jesske Deutsche Telekom AG T Com Zentrale Section T38; Signalling, Gateways and Switching Systems Roland Jesske, T38a12 Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone:  +49 6151 83-5940 Fax:    +49 6151 83-4577 mailto: r.jesske@telekom.de -----Ursprüngliche Nachricht----- Von: Pyrik, Dan [mailto:dpyrik@Brixnet.com] Gesendet: Donnerstag, 15. August 2002 17:26 An: 'sip@ietf.org' Cc: Hedayat, Kaynam; Naylor, Bob; Venna, Nagarjuna Betreff: [Sip] SIP Traceroute using Max-Forwards Hello, I am trying to write an application that performs a "SIP Traceroute" by constantly incrementing the Max-Forwards header starting at 0. The SIP spec states: "The Max-Forwards request-header field may be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. ". However, I do not see how to figure out the IP address of any proxy other than the first outbound proxy. When any other proxy responds with a 483 Too Many Hops packet, it will forward its response along down the proxy chain and the client will receive the response packet with the IP source address set to the first outbound proxy. There is nothing within the SIP packet to show who the originator of the response packet is (without using Record Route headers). Is there any way to get this to work? Thanks, Dan Pyrik Brix Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 16 09:52:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15721 for ; Fri, 16 Aug 2002 09:52:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02326 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 09:53:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01022; Fri, 16 Aug 2002 09:27:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00988 for ; Fri, 16 Aug 2002 09:27:41 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14701 for ; Fri, 16 Aug 2002 09:26:18 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA23851; Fri, 16 Aug 2002 14:27:06 +0100 (BST) Received: from putney.vfl.vodafone (putney [10.33.112.118]) by mailguard4 (4.6.1.91) with ESMTP id ; Fri, 16 Aug 2002 14:26:00 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Aug 2002 14:23:21 +0100 Message-ID: To: jh@lohi.eng.song.fi, utero@bugs.cs.nthu.edu.tw Cc: sip@ietf.org Subject: RE: [Sip] SIP Server Roaming Problem Date: Fri, 16 Aug 2002 14:27:08 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Anthony, If the MN you are thinking of is a 3GPP compliant device then please refer to the 3GPP specifications: TS 23.228, 24.228 and 24.229 Best Regards, Duncan -----Original Message----- From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] Sent: 16 August 2002 12:55 To: Anthony Liu Cc: sip@ietf.org Subject: [Sip] SIP Server Roaming Problem Anthony Liu writes: > If this MN happens to move into a foreign network that wishes any > MN in it contacting its SIP server instead of the one in home network, > do we have a mechanism for this? if you talk about MN that uses the 3g system, then there is no choice whatsoever. the MN is in the walled garden as defined by the guardians of the garden. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 daemon@optimus.ietf.org Fri Aug 16 11:15:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18598 for ; Fri, 16 Aug 2002 11:15:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07007 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 11:16:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05424; Fri, 16 Aug 2002 10:48:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05396 for ; Fri, 16 Aug 2002 10:48:19 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17509 for ; Fri, 16 Aug 2002 10:46:57 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7GEl2I02843; Fri, 16 Aug 2002 09:47:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 09:46:48 -0500 Message-ID: From: "Sriram Parameswar" To: "'Jesske, R'" , dpyrik@Brixnet.com, sip@ietf.org Cc: khedayat@Brixnet.com, bnaylor@Brixnet.com, nvenna@Brixnet.com Subject: RE: [Sip] SIP Traceroute using Max-Forwards Date: Fri, 16 Aug 2002 09:46:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24533.BF6C0010" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24533.BF6C0010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan, The use of Max Forwards to perform TraceRoute is detailed in Section 11 = of RFC 3261 (SIP). I quote below: Alternatively, a server receiving an OPTIONS request with a = Max-Forwards header field value of 0 MAY respond to the request regardless of the Request-URI.=20 This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values.=20 HTH, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jesske, R [mailto:R.Jesske@telekom.de] Sent: Friday, August 16, 2002 7:13 AM To: dpyrik@Brixnet.com; sip@ietf.org Cc: khedayat@Brixnet.com; bnaylor@Brixnet.com; nvenna@Brixnet.com Subject: AW: [Sip] SIP Traceroute using Max-Forwards Hello Dan and all From my understanding the Max Forward header is used for decrementing a value to avoid circular routing. Also there is a proposal within ITU = for the SIP-ISUP mapping to map the Hop-Counter to the Max-Forward Header and = vice versa to avoid circular routing. Therefore I think it is not a good idea to use the Max Forward for incrementing a value. Because if one domain increments the Max Forward Header and the other decrement it, you will never have a mechanism that avoids circular = routing. Please correct me if I misunderstood your mail. =20 Best regards Roland Jesske Deutsche Telekom AG T Com Zentrale Section T38; Signalling, Gateways and Switching Systems=20 Roland Jesske, T38a12 Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone:=A0 +49 6151 83-5940=20 Fax:=A0=A0=A0 +49 6151 83-4577=20 mailto: r.jesske@telekom.de =20 -----Urspr=FCngliche Nachricht----- Von: Pyrik, Dan [mailto:dpyrik@Brixnet.com] Gesendet: Donnerstag, 15. August 2002 17:26 An: 'sip@ietf.org' Cc: Hedayat, Kaynam; Naylor, Bob; Venna, Nagarjuna Betreff: [Sip] SIP Traceroute using Max-Forwards Hello, I am trying to write an application that performs a "SIP = Traceroute" by constantly incrementing the Max-Forwards header starting at 0. The = SIP spec states: "The Max-Forwards request-header field may be used with = any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be = failing or looping in mid-chain. ".=20 However, I do not see how to figure out the IP address of any proxy = other than the first outbound proxy. When any other proxy responds with a 483 = Too Many Hops packet, it will forward its response along down the proxy = chain and the client will receive the response packet with the IP source = address set to the first outbound proxy. There is nothing within the SIP packet = to show who the originator of the response packet is (without using Record Route headers). Is there any way to get this to work?=20 Thanks, Dan Pyrik Brix Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C24533.BF6C0010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] SIP Traceroute using Max-Forwards

Dan,

The use of Max Forwards to perform TraceRoute is = detailed in Section 11 of RFC 3261 (SIP). I quote below:

<Quote>
Alternatively, a server receiving an OPTIONS request = with a Max-Forwards header field value of 0 MAY respond to the request = regardless of the Request-URI.

This behavior is common with HTTP/1.1. This behavior = can be used as a "traceroute" functionality to check the capabilities = of individual hop servers by sending a series of OPTIONS requests with = incremented Max-Forwards values.

</Quote>

HTH,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Jesske, R [mailto:R.Jesske@telekom.de]
Sent: Friday, August 16, 2002 7:13 AM
To: dpyrik@Brixnet.com; sip@ietf.org
Cc: khedayat@Brixnet.com; bnaylor@Brixnet.com; = nvenna@Brixnet.com
Subject: AW: [Sip] SIP Traceroute using = Max-Forwards


Hello Dan and all
From my understanding the Max Forward header is used = for decrementing a value to avoid circular routing. Also there is a = proposal within ITU for the SIP-ISUP mapping to map the Hop-Counter to = the Max-Forward Header and vice versa to avoid circular = routing.

Therefore I think it is not a good idea to use the = Max Forward for incrementing a value.
Because if one domain increments the Max Forward = Header and the other decrement it, you will never have a mechanism that = avoids circular routing.

Please correct me if I misunderstood your mail.  =

Best regards


Roland Jesske


Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching = Systems
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:=A0 +49 6151 83-5940
Fax:=A0=A0=A0 +49 6151 83-4577
mailto: r.jesske@telekom.de <mailto:r.jesske@telekom.de> =



-----Urspr=FCngliche Nachricht-----
Von: Pyrik, Dan [mailto:dpyrik@Brixnet.com]=
Gesendet: Donnerstag, 15. August 2002 17:26
An: 'sip@ietf.org'
Cc: Hedayat, Kaynam; Naylor, Bob; Venna, = Nagarjuna
Betreff: [Sip] SIP Traceroute using = Max-Forwards


Hello, I am trying to write an application that = performs a "SIP Traceroute"
by constantly incrementing the Max-Forwards header = starting at 0. The SIP
spec states: "The Max-Forwards request-header = field may be used with any SIP
method to limit the number of proxies or gateways = that can forward the
request to the next downstream server. This can also = be useful when the
client is attempting to trace a request chain which = appears to be failing or
looping in mid-chain. ".
However, I do not see how to figure out the IP = address of any proxy other
than the first outbound proxy. When any other proxy = responds with a 483 Too
Many Hops packet, it will forward its response along = down the proxy chain
and the client will receive the response packet with = the IP source address
set to the first outbound proxy. There is nothing = within the SIP packet to
show who the originator of the response packet is = (without using Record
Route headers). Is there any way to get this to = work?
 Thanks,

Dan Pyrik
Brix Networks


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

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

------_=_NextPart_001_01C24533.BF6C0010-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 16 14:00:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25502 for ; Fri, 16 Aug 2002 14:00:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19423 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 14:02:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18107; Fri, 16 Aug 2002 13:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18037 for ; Fri, 16 Aug 2002 13:41:42 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24794; Fri, 16 Aug 2002 13:40:20 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7GHf1h01323; Fri, 16 Aug 2002 13:41:01 -0400 (EDT) To: "Sriram Parameswar" Cc: bnaylor@Brixnet.com, dpyrik@Brixnet.com, khedayat@Brixnet.com, nvenna@Brixnet.com, "'Jesske, R'" , sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] SIP Traceroute using Max-Forwards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 16 Aug 2002 13:40:59 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/16/2002 01:39:04 PM, Serialize complete at 08/16/2002 01:39:04 PM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA18039 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit To address the remaining open question: How do you figure out the address of the entity that was the last node ? In typical ICMP, the entity that receives TTL sets to 0, sets its own IP address in the ICMP response. However ,in the case of SIP , the Via header in the response will contain the address of the previous hop (x-1) entity not the one that responded (x). To get the address of X, you would have to increase Max-Fwd by 1 to ensure that this time, x is not the terminating entity. Therefore, it seems the difference b/w traditional traceroute and SIP level is that you would need to "go one hop ahead" of X to get the address of X. Again, the other thing is that in ICMP traceroute , there is no absolute guarantee that the next iteration will trace the same path as the previous path. That does not seem to be a stumbling block in SIP ->t o help solve this problem, am I correct in saying that Dan has to implement the source routing record-route to ensure that subsequent paths follow the previous path-set ? It is also possible that if you send an OPTIONS the entity that responds with 200OK embeds its address in some place in the SDP which could account for reachability -> but then this is not standard and no process has been defined for it (to my knowledge) in which case you dont need to "go one hop ahead" to arrive at the address of the previous node. -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 "Sriram Parameswar" Sent by: sip-admin@ietf.org 08/16/2002 10:46 AM To: "'Jesske, R'" , dpyrik@Brixnet.com, sip@ietf.org cc: khedayat@Brixnet.com, bnaylor@Brixnet.com, nvenna@Brixnet.com Subject: RE: [Sip] SIP Traceroute using Max-Forwards Dan, The use of Max Forwards to perform TraceRoute is detailed in Section 11 of RFC 3261 (SIP). I quote below: Alternatively, a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. HTH, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jesske, R [mailto:R.Jesske@telekom.de] Sent: Friday, August 16, 2002 7:13 AM To: dpyrik@Brixnet.com; sip@ietf.org Cc: khedayat@Brixnet.com; bnaylor@Brixnet.com; nvenna@Brixnet.com Subject: AW: [Sip] SIP Traceroute using Max-Forwards Hello Dan and all From my understanding the Max Forward header is used for decrementing a value to avoid circular routing. Also there is a proposal within ITU for the SIP-ISUP mapping to map the Hop-Counter to the Max-Forward Header and vice versa to avoid circular routing. Therefore I think it is not a good idea to use the Max Forward for incrementing a value. Because if one domain increments the Max Forward Header and the other decrement it, you will never have a mechanism that avoids circular routing. Please correct me if I misunderstood your mail. Best regards Roland Jesske Deutsche Telekom AG T Com Zentrale Section T38; Signalling, Gateways and Switching Systems Roland Jesske, T38a12 Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone:  +49 6151 83-5940 Fax:    +49 6151 83-4577 mailto: r.jesske@telekom.de -----Ursprüngliche Nachricht----- Von: Pyrik, Dan [mailto:dpyrik@Brixnet.com] Gesendet: Donnerstag, 15. August 2002 17:26 An: 'sip@ietf.org' Cc: Hedayat, Kaynam; Naylor, Bob; Venna, Nagarjuna Betreff: [Sip] SIP Traceroute using Max-Forwards Hello, I am trying to write an application that performs a "SIP Traceroute" by constantly incrementing the Max-Forwards header starting at 0. The SIP spec states: "The Max-Forwards request-header field may be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. ". However, I do not see how to figure out the IP address of any proxy other than the first outbound proxy. When any other proxy responds with a 483 Too Many Hops packet, it will forward its response along down the proxy chain and the client will receive the response packet with the IP source address set to the first outbound proxy. There is nothing within the SIP packet to show who the originator of the response packet is (without using Record Route headers). Is there any way to get this to work? Thanks, Dan Pyrik Brix Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Aug 16 14:46:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27573 for ; Fri, 16 Aug 2002 14:46:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21437 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 14:47:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20874; Fri, 16 Aug 2002 14:31:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20807 for ; Fri, 16 Aug 2002 14:31:27 -0400 (EDT) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26851 for ; Fri, 16 Aug 2002 14:30:04 -0400 (EDT) Message-ID: <20020816183125.81028.qmail@web11608.mail.yahoo.com> Received: from [207.46.225.252] by web11608.mail.yahoo.com via HTTP; Fri, 16 Aug 2002 11:31:25 PDT Date: Fri, 16 Aug 2002 11:31:25 -0700 (PDT) From: Sean Olson Subject: RE: [Sip] SIP Traceroute using Max-Forwards To: Arjun Roychowdhury , Sriram Parameswar Cc: bnaylor@Brixnet.com, dpyrik@Brixnet.com, khedayat@Brixnet.com, nvenna@Brixnet.com, "'Jesske, R'" , sip@ietf.org, sip-admin@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --- Arjun Roychowdhury wrote: > To address the remaining open question: > > How do you figure out the address of the entity that > was the last node ? > In typical ICMP, the entity that receives > TTL sets to 0, sets its own IP address in the ICMP > response. However ,in > the case of SIP , the Via header in > the response will contain the address of the > previous hop (x-1) entity not > the one that responded (x). I think there may be some confusion here. The Via: headers will provide no information to the originator of the OPTIONS request as these are consumed in the reverse path. In fact, there is no way in the base SIP specification to get the ICMP traceroute behavior you seek. The closest approximation would be to examine the Record-Route: headers in an INVITE response. If you read the text of RFC3261 carefully: This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values You see that what you get is not the identity of the servers along the path, but rather their capabilities. > Again, the other thing is that in ICMP traceroute , > there is no absolute > guarantee that the next iteration will trace the > same path > as the previous path. That does not seem to be a > stumbling block in SIP > ->t o help solve this problem, am I correct in > saying > that Dan has to implement the source routing > record-route to ensure that > subsequent paths follow the previous path-set ? I guess the real question is what are you trying to accomplish with this "traceoute" behaviour. With stateless proxies in the path, it is quite likely that subsequent OPTIONS will take different paths. This is a good thing. You can, of course, send an OPTIONS within a dialog coupled with record-route to get more deterministic behavior, but again, loose routing makes no guarantees here. If you want to understand the capabilities of the servers that would be involved in procesing a dialog, OPTIONS has everything you need. If you want to diagnose a network failure and pinpoint the source of the failure, OPTIONS is somewhat lacking. > > It is also possible that if you send an OPTIONS the > entity that responds > with 200OK embeds its address in some place in the > SDP which > could account for reachability -> but then this is > not standard and no > process has been defined for it (to my knowledge) in > which > case you dont need to "go one hop ahead" to arrive > at the address of the > previous node. This is a possibility, but non-standard as you mention. It might be useful to publish an informational on this topic which describes the SDP usage you mention. Regards, Sean Olson Microsoft __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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 daemon@optimus.ietf.org Fri Aug 16 14:56:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28036 for ; Fri, 16 Aug 2002 14:56:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21684 for sip-archive@odin.ietf.org; Fri, 16 Aug 2002 14:58:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21239; Fri, 16 Aug 2002 14:40:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21174 for ; Fri, 16 Aug 2002 14:40:01 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27248; Fri, 16 Aug 2002 14:38:39 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7GIdSh21870; Fri, 16 Aug 2002 14:39:28 -0400 (EDT) To: Sean Olson Cc: bnaylor@Brixnet.com, dpyrik@Brixnet.com, khedayat@Brixnet.com, nvenna@Brixnet.com, "'Jesske, R'" , sip@ietf.org, sip-admin@ietf.org, Sriram Parameswar Subject: RE: [Sip] SIP Traceroute using Max-Forwards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 16 Aug 2002 14:39:26 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/16/2002 02:37:32 PM, Serialize complete at 08/16/2002 02:37:32 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think there may be some confusion here. The Via: headers will provide no information to the originator of the OPTIONS request as these are consumed in the reverse path. ARC> Oops my mistake. Yes, you are right -> I incorrectly pointed to Via whereas I meant Record-Route. Again, this has the assumption that all nodes inbetween can and will Record-Route If you want to diagnose a network failure and pinpoint the source of the failure, OPTIONS is somewhat lacking. ARC> I would think this is exactly what Dan seems to want to do, instead of discovering capabilities. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Aug 17 16:38:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03157 for ; Sat, 17 Aug 2002 16:38:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29206 for sip-archive@odin.ietf.org; Sat, 17 Aug 2002 16:39:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28423; Sat, 17 Aug 2002 16:16:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28394 for ; Sat, 17 Aug 2002 16:16:37 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02610 for ; Sat, 17 Aug 2002 16:15:14 -0400 (EDT) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g7HKGLM05999; Sat, 17 Aug 2002 22:16:21 +0200 (MEST) Message-ID: <3D5EAFAA.2030305@tzi.uni-bremen.de> Date: Sat, 17 Aug 2002 22:18:50 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: sip CC: Allison Mankin , Dean Willis , Rohan Mahy , "Rosen, Brian" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Draft SIP Minutes Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, attached are the SIP minutes from the Yokohama meeting. Please double-check that this matches what really happened at the meeting. Thanks, Joerg SIP WG Meeting at the 54th IETF =============================== Minutes by Joerg Ott (jo@ipdialog.com) Notes by Renee Cohen, Vijay Gurbani, and Joerg Ott. The SIP Working Group met twice at the 54th IETF; the sessions were chaired Dean Willis, Brian Rosen, and Joerg Ott. Agenda Bashing and Status Uppdate (Chairs) The meeting agenda was accepted; the only minor change was that the discussion of MIME types was postponed from the first to the second session, pending input from the ADs. A brief overview of the status of the drafts was given, noting that the most important ones are published and quite a few had been finalized (see overview slide from Rohan Mahy) and several ones are moving ahead in the process. One draft, defining the REFER method, had issues found during last call and went back to WG item status (as discussed below). REFER: Open Issues (Robert Sparks) - draft-ietf-sip-refer-05.txt - draft-sparks-sip-refer-3265disc-00.txt - draft-ietf-sip-referredby-00.txt The draft on the REFER method lacked clean documentation on how to use SIP events. A separate document was created (draft-sparks-sip-refer-3265disc-00.txt) that suggests clarifying wording and also defines a mechanism to signal whether or not an implicit subscriptions on reception of a REFER have been created. A poll on the list, however, showed that no one has actually implemented optional subscriptions and hence this mechanism is not needed. It has been agreed to make implicit subscriptions mandatory; a new revision of the REFER draft (-06) will be issued this week including the clarifying text and reflecting the list agreement. The AD (Allison Mankin) remarked that this change will not require another IETF Last Call; as no one saw a need for another WG Last Call was, the document will be send to the IESG queue where it left off when the issues were encountered. As another change the REFER draft was split into two parts after the SIP interim meeting, factoring out the Referred-By: header (which had strong security issues that were not resolved in the original document). The Referred-By draft now makes use of the S/MIME mechanism. So far, there has been only very little discussion on the list and no issues have come up that would warrent discussion at the meeting. People are encouraged to review the draft. MESSAGE: Open Issues (Ben Campbell) - draft-ietf-sip-message-05.txt The MESSAGE draft is currently in IETF Last Call and is waiting for IESG feedback. Minor changes have been made so far in response to feedback. The major issue of this draft is congestion control. Quite some concern has been raised about the artificial message size limit. The updated draft provides compromise wording for this: while specifying a size limit, it also states that this may be exceeded if the sender is sure that all links on the path are congestion-safe. The draft does not specify how a UAC determines that this condition is satisfied. A new draft on SIP and congestion control (discussed later in this session) addresses this issue. Furthermore, the use of the Expires: header has been clarified: it is now suggested that a value of 0 shall indicate that immediate delivery is requested. Delta-time stamps (from the Date: header, if present, or time of reception, otherwise) are provided for as absolute times. If an Expires: header is present, a Date: header should also be provided. Treatment of expired messages is up to the local policy at the UAS. Finally, it has been suggested that UACs "MUST" register with the parameter methods="MESSAGE", which is currently a SHOULD. Discussion has shown that people are in favor of leaving this a "SHOULD" (as with all other methods) as is written in the current draft. It was agreed to keep the "SHOULD". Caller Preferences Open Issues (Jonathan Rosenberg) - draft-ietf-sip-callerprefs-06.txt The caller preferences work has been around for quite some time and has experienced little use in the past. The latest update of the draft makes use of RFC 2533, with significant simplifications though to keep caller preferences simple and straightforward to implement: the the general idea is used, the allowable input is significantly restricted, however, and the syntax is kept backward compatible. In particular, only a conjunctive normal form is needed, i.e. a disjunction with each term being expressed as a conjunction of feature tags. Computing the interscetion between two such terms can be done linearly without the complexity that comes with the full RFC 2533 algorithm. Note also that RFC 2533 is used only internally: the syntax on the wire has not been changed but the internal processing rules have, to comply with the simplified version of RFC 2533. A number of semantics changes have also been made: firstly, RFC 2533 already supports MIME types, but differently from how caller preferences have been using it before. The "type" tag as already registered by RFC 2533 allows only complete MIME types, no wildcards as were used before. Therefore, two tags are now used by caller preferences: the "type" tag as per RFC 2533 and an additional "media" tag carrying top level types for alignment with existing tags. Note that this breaks backwards compatibility here. A Boolean "automata" tag has been added to indicate e.g. voice mail server, robots, etc. and an "events" tag to indicate support for RFC 3265 event types. There have also been some changes in priority matching rules: multiple ones can be specified and Accept-Contact: header allows for explicitly asking for a certain priority. The weighing parameter Q now needs to be the last parameter amongst the Accept/Reject-Contact header values. New is also the way of explicitly specifying preferences: previously, methods and priority information were handled differently from other preferences; while the latter were explicitly specified, the former were inferred from the request method and the priority header. The revised version of the draft allows to also specify those explicitly. The implicit variant is still supported but is overridden by the explicit one. Further changes include a significantly restricted URI matching: either user and host are matched or just the host. In all cases, URI parameters are now ignored. Also, the feature sets that can be present in Accept-Contact: (INVITE) and Contact: (REGISTER) headers have been unified and are now able to express exactly the same information. Finally, the "&" construct has been removed for a single tag as each tag represents one axis in an n-dimensional space; the feature collection is represented as a point in this n-dimensional space and there must not be more than one value on the same axis; hence, the "&" construct does not make sense here. During the discussion, the need was identified to express more than one value for some given tags (e.g. audio, video for media) and hence those cannot be part of the same dimension. It was suggested to use a Boolean tag for each media type instead (e.g. audio=yes, video=yes) so that independent dimensions are created. As this approach was agreed, the issue was raised how to manage the resulting name space: for each new MIME type, a new tag would need to be registered and name clashes may come up. Proxies do not have to be aware of registered values; they just process "tag=value" pairs, regardless of whether or not "tag" or "value" are registered. Therefore, this was deemed a minor problem that should be dealt with when real (rather than theoretical) issues arise. For now, some clarifying statement regarding the modified use of the tags will be included in the next revision of the draft. Finally, two open issues were discussed: When used in the Contact: header within an INVITE transaction to declare one's own features, various parameters overlap with SIP headers (e.g. methods and Allow:, Events: and Allow-Events:, etc.). This can be resolved in numerous ways: (1) allow both and define one to take precedence over the other, (2) forbid caller preferences from using parameters that are also present through headers, and (3) disallow the use of caller preferences in INVITE/200. The proposal to choose (1) with headers taking priority was accepted. The other issue refers to extensions to parameters that result from work other than caller preferences: there is no way to indicate that a certain Contact: parameters actually belongs to caller preferences as opposed to being some other extension. Discussion has shown that it actually does not matter: unless the same parameter is present in both the calling and the called entity's Contact: parameters, they will simply be ignored. This is found to also address the issue of the earlier discussion on naming and registration of tags. The revised draft will state this as an issue but will also point out that it does not really matter. At least one more revision of the draft will be needed, taking into account discussions during this meeting as well as feedback received by mail. SIP NAT Open Issues (Jonathan Rosenberg) - draft-ietf-sip-nat-02.txt The previous version of the draft addressed two different problems: (1) receiving responses through a NAT ("rport" parameter) and (2) receiving requests through a NAT (Translate: header in REGISTER). The Translate: header had various issues: for UDP, frequent re-registrations are required; it introduces NAT-specific parameters; and it duplicates STUN. The revised draft is scoped to do exactly what is needed to make SIP work with STUN, SPAN, and TURN -- no more, no less. As a result, only the "rport" parameter remains as, without this, STUN would not work. In the long run, TCP (or better: TLS) is the right answer and, in this case, only the registration problem needs to be solved. A point was made that MMUSIC was already dealing with such efforts but Jonathan responded that the MMUSIC work affected the SDP and thus the media streams; the work he presented here was purely for SIP. Some discussion arose around encouraging people to move to IPv6 (as opposed to applying fixes to "evil" IPv4 equipment such as NATs). The point was made, however, that the SIP NAT has actually broader applicability and does not just deal with NATs. This will be reflected in a renaming of the draft in the next revision, then again as a -00 draft. The document is now rather short and cleaned up; WG Last Call will be issued soon. Session Timer (Brian Rosen) - draft-ietf-sip-session-timer-09.txt No one in the group had any issue with session timer. Digest Authentication Enhancement Open Issues (James Undery) - draft-undery-sip-auth-01.txt Current authentication for SIP is essentially based upon RFC 2617: it is deployed today, it is simple, and works for UAC-to-UAS as well as for UAC-to-proxy. The last revision of the authentication enhancement draft was perceived by far too complex so quite some complexity was taken out and only a few core items remain: fixes to authentication, bid-down protection, and header integrity protection. A "realm" parameter was added to Authentication-Info: and a generic extension mechanism was included in case future authentication algorithms would need different parameters from those required by digest authentication. To counteract bid-down attacks, the proposed algorithms and the "qop" parameter are included in the nonce. To provide header integrity protection, a message/sipfrag may be included in the body. The only open issue raised was on the acceptance of this work in general: do people find this extension too much or do they want it. Numerous people strongly supported the idea; in particular, the work was viewed as urgently needed: it should be progressed quickly or halted (to pursue some other approach) -- but not hang around endlessly. S/MIME was brought up as desirable but others stated that, particular with small devices, not too many of them will be doing S/MIME (just for the purpose of registration). Hence a simpler way is needed. Basically, S/MIME can be shrunk or digest can be extended. For the former, however, there had been no proposals so far. So this draft may be the right way ahead. Other comments were made to provide more detail on bidding down attacks and possibly make recommendations which algorithms (not) to use. Another comment raised that digest itself is insecure and should not be used at all. James indicated that the algorithm he proposed was not specific to digest; if the two ends decide to use digest they know that they took a concious decision without interference from a man-in-the-middle. The chairs concluded that they'll have a discussion with their security advisors on this and try to move this work along. SIP Congestion Safety (Dean Willis) - draft-willis-sip-congestsafe-00.txt Dean presented the general problem background on SIP and congestion control. SIP allows for UDP and TCP/SCTP as transport protocols. The use of UDP brings along a number of problems. With TCP and SCTP, multiple transactions may share the same transport connection including their retransmission timers. For UDP, however, SIP defines retransmission timers with exponential backoff on a per transaction basis. Using UDP, a node may be involved in a number of independent transactions at the same time, without having those transactions share the congestion state (timers, etc.) with each other. No standard way is defined to adapt (re)transmission behavior across multiple independent transactions to changing network conditions. Proxies may even change the transport to UDP, so the originating UA has no knowledge whether or not TCP or SCTP will be used all the way. A similar problem exists if the proxies do not re-use TCP connections but rather open up new ones for new transactions (but for TCP, connection re-use is at least being defined to deal with this problem). Another issue with UDP are large SIP messages: if messages get larger than the MTU size, IP fragmentation will result in sequences of fragments with no inter-fragment rate limiting. RFC 3261 "solves" the problem by imposing an artificial upper limit of 1300 bytes on a message sent by a UA if the messages may ever traverse a non-congestion controlled link. As transport may be changed by proxies, UAs should essentially never send messages larger than 1300 bytes -- but messages of larger size will be required, e.g. because of S/MIME, MESSAGE bodies, etc. RFC 3261 does not provide a solution -- unless networks are engineered in a way that only TCP is used between proxies. Some backwards compatibility issues are raised indicating that one may be required to use UDP (which is countered stating that even RFC 2543 need to support TCP). Dean further presented traffic models to outline the problem; this part provoked quite some discussion on suitability of the model presented and how much it represented actual traffic on the Internet. It was also questioned that TCP-style congestion control could be applied to all kinds of traffic in the Internet. The discussion continued for quite some time before being brushed away by the AD (Allison Mankin) aksing people to focus again on SIP congestion issues rather than engaging in general debates on congestion control. As a valid point remaining from the discussion, it was also noted that the first traffic model did not actually compare UDP to TCP but rather a single "connection" to a number of independent parallel "connections". But this was addressed by Dean anyway in his "Corrected Scenario". After this background discussion, Dean discussed the contents of the draft itself: it essentially defines the congestion problem and congestion-safe behavior by making a couple recommendations: it states a strong preference for TCP/SCTP over UDP and disallows two concurrent transactions in the same direction between any two nodes (which essentially enforces a 2*RTT rate lock step rate limiting). It also sets out to define mechanisms that allow UAs to determine that their requests will be handled in a congestion-safe manner. An issue was brought up whether this would also apply to traffic which is not best-effort but somehow treated preferentially; since in essence, one cannot know what kinds of lower layer services to expect, the same behavior as for best-effort is expected. Just using TCP, however, is not enough: TCP with connection re-use is what is needed; this was reinforced several times. It was also pointed out that proxies must be able to restrict the overall traffic they transmit: in case they talk to 500 other proxies with bits of traffic sent to each of these, this will gain very little in terms of congestion control, unless the proxies consider all the traffic it is sending to the network. The congestion-safety framework should not preclude this. Another speaker felt the draft was talking too little about considerations for big messages and the implications for that. As something like that was intended to be in there, further text will be provided. In addition, proxies could be enabled to reject large requests in case they know the following path is not congestion-safe, thereby asking the client to send smaller pieces and pace itself. In response, it was pointed out that it's not just the request, however: the response has far less choices of which ways to take and there is no way to signal to its sender that it is too big. Dean also outlined two simplifications that have been proposed: the use of UDP could be restricted to the link between a wireless UA and its edge proxy (3G scenario). In SIP, however, there is no way to determine up front whether the next hop is going to be a proxy or a UA; hence this would need to be ensured by network design. Also, it has been proposed to deprecate UDP entirely from being used in the SIP spec (which, of course, bears a huge backwards compatibility issue). Dean does not believe it can be simplified to either or the too but he is willing to undertake the effort if there is strong support. Another issue to discuss (and there has been quite some controversy among the draft authors) is when congestion-safe behavior should be followed by proxies: always or only if the UA explicitly "requires" it. The former would greatly reduce the UDP throughput, while the latter would prevent non-upgraded endpoints from flooding the network with packets. This is an open issue. A strong position was taken to make congestion control a top priority in the WG. This work should not be seen as an extension to SIP but rather as a task migrate from existing behavior to something new. And this new behavior should then be applied all the time. There will be some time before SIP goes to draft standard (1.5 - 2 years) and this time can be used to upgrade all the SIP elements (UAs that do only UDP, proxies that are not congestion-safe) to match this new behavior; hence there is sufficient time for everyone to adapt. The approach must be backwards compatible but, as the proxies already are required to support TCP, new elements can just replace old ones piece by piece. Strong support was expressed that this behavior should be exercised all the time. There may not be all the right mechanisms at hand now but the group is definitly on the right track. While TCP may sometimes increase load for few and small messages, small messages will go away and so will the possibility to use UDP all. It was emphasized again that in the mid-term UDP should go away. Some minor implementation issues were discussed regarding TCP fan outs from UAs and proxies. It was established that practice has proven that large-scale fan-outs can be done. A mechanism to indicate that congestion-safe treatment is required. While only a Require: header is present in the current draft, a Proxy-Require: header is needed as well. The final question raised was whether the mechanisms just outlined and discussed are strong enough to ensure reasonably good behavior of SIP proxies and UAs. The general feeling seems to be: yes. Some work on the rules and mechanisms is still required. Open Mike With ten minutes agenda time left, an open mike session was started which, after a brief discussion on WG items, again took up the issue of congestion control. The group agreed to make congestion control a WG item. Some further discussion emerged with the point being made that just using TCP would, by the nature of the traffic, not solve the congestion problem as a whole (one needs to do more). Also, it's not just congestion control why one would want to use TCP in the first place but security: from making it more complicated to inject packets to being able to fully secury connections. As for congestion, traffic peaks in proxies also need to be dealt with -- by using the mechanisms available today in SIP. Another issue: there may be messages the size of which cannot be reduced in case a proxy rejects them; in this case, a different route may need to be used. Mechanisms may be needed that allow a proxy to reject a request indicating that a different transport should be used. It was also pointed out that TCP keep-alives need to be turned off as they would cause too much traffic otherwise. Session 2 --------- The second session started with a modification in the agenda: the discussion of a draft on SIP-ISUP mapping which had been left over from the SIPPING meeting on the previous day was added right in the beginning. Beforehand, a the enormous achievements of the editors and ADs involved in making the huge task of RFC 3261 happen were recognized with a big applause. Following this, it was agreed to publish the changes between bis-09 and RFC 3261 rather quickly and a process for logging and collecting bugs in RFC 3261 was outlined. The plan is to go to draft standard after some time and the logging procedure shall help to ensure that all issues encountered in the past are actually rolled in. SIP-ISUP Mapping (John Elwell) - draft-elwell-sipping-qsig2sip-01.txt This draft originates from ECMA (European Computer Manufacturer Association) who have developed QSIG. QSIG is a standard for interconnecting PBXes in private networks. The QSIG-SIP interworking draft is intended to enable integration of traditional telephony and SIP-based VoIP within an enterprise and thus allow a smooth evolution of enterprise networks from QSIG to SIP. The draft specifies a mapping from QSIG to SIP and vice versa; it does not handle encapsulation. The draft complements the work on SIP to ISUP mapping. The following issues were identified: Q.850 cause mapping is not yet entirely done; there are still differences compared to the ISUP draft but those should be compatible. Work has progressed during the IETF week and there will eventually be a line cause mapping. Another issue is overlap sending; the QSIG work is technically in line with the ISUP work but, since the other draft is written using ISUP terms, the text could not just be referenced but needed to be adapted. A final issue is whether or not ISDN (DSS1) interworking should be specified in the draft. Because of numerous (partially large) differences between QSIG and ISDN and numerous scenarios that could be/would need to be specified, it is suggested to keep this work entirely separate. A comment was raised that the draft should include extra functionality as well and not restrict itself to addressing the basic call scenario. John responded that, as basic calls are a prerequisite for the rest, this should be addressed first. The rest should follow in later RFCs. Another commenter pointed out that MIME encapsulation for QSIG is specified separately and can just be used. It was found that the draft seems to take the right direction and commenters agreed with keeping DSS1 mapping separate. The work should move ahead but, as the charter is currently pretty full, it should take one more round as individual draft before becoming a SIPPING WG item (aimed at PS). The way ahead for the draft will be discussed on the mailing list; the WG chairs will consult with their ADs beforehand. Identity open issues (Jon Peterson) - draft-peterson-sip-identity-01.txt The SIP privacy and network asserted identity have passed IESG and are thus finished: in just six weeks from a -00 draft to RFC, some kind of a record. A comment was made that this pace was only possible because many comments were ignored. However, the presenter claimed that the concerns were addressed and debated on the list in length and this should not be repeated right now. The chairs pointed out that rough consensus is good enough for the IETF, unanimity is not needed; so this work is done and one should move on. The next draft discussed addresses SIP identity in the long term, moving away from the closed trust domain model required to assert and verify the identity as it has been developed for 3G needs. This work is already a WG item even though it has been submitted as an individual contribution once more this time. The revised draft incorporates numerous comments received on the initial version, some of which are significant open issues as discussed in the following. The first major open issue is how to identify the authentication service in a given administrative domain as the hostname convention used in -00 has been removed and was not replaced by something else. This leaves open who -- i.e. which (single) entity in a domain -- is responsible for asserting an identity and thus can be verified by recipients of the asserted identity. Related to this is what information about the authentication service can be derived from knowing this entity: is it *the* host responsible for the entire domain (e.g. yahoo.com) or just *one* host within this domain (e.g. xyz.yahoo.com); this may have an impact on how trustworthy the asserted identity is to the receiver. Discussion came up that this depended on what the asserted identity and the knowledge about the asserting entity should be used for. One might not care which host actually did the signing/assertion (hosts may change daily anyway) as long as the signature was ok and one could verify it came from the right party. In essence, a UA should be able to express/restrict who is supposed and/or allowed to sign the asserted identity so that the right representative is chosen. This requires a naming convention of some sort but that name should/need not be a host name. It would be nice if the receiver could, by some convention, determine which is the privileged entity for a given domain without the need for any pre-arrangements; this is the property sought (which got lost by removing the host name convention). It was also noted, however, that the asserting identity need not be part of the same domain and hence such (host) naming convention might not even make sense. The necessary feature could, as was recommended by some security folks, be attached as new certificate properties; involving new certificate characteristics and certification authorities, such an approach was felt to take a while to be realized and hence impractical for the shorter term. The discussion concluded in recognizing that the entire problem may not be that well understood at this point in time and further experience will be required. As a consequence, the group may not want to say anything specific right now; but the desire was expressed to do better than this and continue to try to find some solution here. Another issue was whether to include and thus sign the entire SIP message or just parts of it -- the basic question of how many headers need to be signed. The solution right now in the draft is to allow for both message/sip as well as message/sipfrag as MIME contents to be signed. At least three headers are required, more are allowed. Finally, the privacy pieces of the draft were aligned with the short-term network asserted identity draft to get unified behavior. There is other minor stuff to be done. Work is continuing. BINDing URIs to SIP AORs (Henning Schulzrinne) - draft-schulzrinne-sip-bind-00.txt This new draft addresses the issue of associating data intended for or carried in an external protocol as well as actions with a SIP address-of-record. Providing CPL and SIP CGI scripts, uploading presence information, user provisioning and configuration are examples. There are many facets to this problem and many ways of solving it. The present proposal defines just one approach. The idea is to associate a SIP AoR or a SIP UA's URL with one or more URIs that can be used to retrieve data or to invoke the desired actions. This allows for binding information, modifying information, and deleting bindings. Various types of indirection are supported: a URI may point to the information which may be retrieved from an external location or included in a message body; small amounts of information may also be encoded within the URI itself. The binding concept discussed here and the concept of content indirection have some commonalities in that both refer to external data but the semantics are different: content indirection is used to replace data otherwise carried within a message body by the data the URI references while bindings are used to link external data to an AoR (with this binding being valid for more than just a single message). The document proposes a Binding: header field with a number of parameters ("disposition", "expires", and "etag") to control the actions to be taken for a particular binding. Any number of Binding: headers may be present in a message. In addition, a specific BIND method is defined to decouple creating and modifying bindings from user registration; its basic implementation is pretty similar to the REGISTER method. The first open issue raised by Henning was whether or not this approach solves some of the problems that we have in a reasonably generic fashion. The second question is whether the proposal addresses the right set of applications. Third, may a generalized version of PUBLISH solve the binding problems as well? While Henning sees views this to be unlikely, it still may need to be discussed. Henning also talked about a few details but wanted the discussion to focus on the general problem. He also pointed out that, not yet contained in the draft, BIND requests may be routed following caller preferences and thus need not go to the registrar, effectively allowing any entity to become a repository for bindings. There was strong agreement that bindings are needed (and that they are needed soon) and also that the mechanisms are likely to be different from the PUBLISH method. It was also found that this may go well together with service route discovery, configuration, boot strapping, and other work that has been going on recently. Overall, it is important to carefully scope this work: one may do quite a bit with such an approach but, at the same time, it can also turn out to be an infinite rathole of potential abuses (with quite some difficulty to tell what is an abuse and what is not). It is unclear what types of "disposition" are legitemately bound to a URI and which are not. People felt that nothing was wrong with the mechanism but that semantics would need to be more clearly understood and defined and so should be the intended uses. If one finds alternatives for each single use case, this specific proposal may not be needed at all. Another speaker pointed out that this could be a nice and lightweight rendezvous mechanisms for simple devices; abuse should be avoided, however. The author pointed out that, if pursued further, the mechanism should stay relatively simple. From the overall argument, the group appears to be split: some people want this yesterday, others may not want it at all. Humming revealed quite some support but also opposition, thus confirming the impression from the debate. SIP Compression open issues (Carsten Bormann, Gonzalo Camarillo) - draft-ietf-sipping-sigcomp-sip-dictionary-03.txt - draft-camarillo-sip-compression-01.txt Carsten Bormann presented on the current status of SIP compression. The signaling compression work is essentially complete; the documents are in the RFC editor's queue and have even been assigned RFC numbers. There are two loose ends remaining which may fit into the SIP WG: the static dictionary for signaling compression and the integration of signaling compression with SIP. The static dictionary contains a set of well-defined strings that are used by SIP and SDP; currently, this table is about 4,000 bytes in size and is partitioned into five priorities. There are only a few open issues remaining: the recent changes in SIP documents need to be tracked and corresponding additions/modification need to be incorporated in the dictionary. The most interesting issue here is when to stop tracking. There is obviously no single right point in time for doing so. The dictionary should be as complete as possible to gain most efficient compression from the very first message exchange. However, while developed in the context of 3G requirements, the dictionary is of much broader applicability, so one should not wait too long to enable devices and applications to make use of it as soon as possible. Since the dictionary, once published, is not going to change anymore, it should still be as complete as possible. Hence, one of the key questions is which additional words are missing right now; along with this, it should be rationalized which keywords will be included and which ones won't. Headers that are too specific should not be included; the size of the dictionary should not double. A key point here are P- headers: many people may have P- headers they want to see documented tomorrow, but the most likely ones (such as those from the 3G community) should be; the proposal is to separate the "P-" from the remaining header name and just put in "words". This approach was accepted and all the SIP specs will be reviewed again to make sure that nothing important is missing. The group agreed that the best thing would be stop adding to the dictionary "now", i.e. as soon as this review is complete. As second speaker, Gonzalo Camarillo addressed how to signal compression within SIP. The current draft specifies a new parameter -- "comp=sigcomp" -- for use in two places: in the SIP URI and in the Via: header. The parameter is meant to express willingness to compress rather than support for compression; this distinction shall help to use compression only where is makes sense. The draft is quite short and Gonzalo expects it to be uncontroversial but still asks for feedback about the general idea. Humming indicated quite some support and only a bit of opposition. The WG will consider this as a WG item, pending AD approval. The next steps are (1) to determine how to get SIP URI with the "comp=sigcom" parameter in it and (2) to do an interop -- a real or a virtual one -- on this work. The SIP interop meeting in Atlanta in October is considered a suitable place for such an event. Robert Sparks has volunteered to contribute to organizing the interop and generating the test cases. The first issue, how to identify that a certain SIP URI can and/or should be contacted using sigcomp, provoked further discussion. In particular, that "comp=sigcomp" is attached to a SIP URI needs to be learned dynamically. This holds true for endpoints as well as for first hop (outbound) proxies (for the first message they send). To make use of the dictionary (for the first message) at all, a SIP entity that wants to transmit a message needs to know up front whether it can compress it or not. There may also be more options one may want to discover than just sigcomp, linking this to configuration in general. Configuration protocols such as DHCP (where a SIP option already is included, even though it is insufficient for this purpose) or PPP should provide this information, preferrably in URI parameters as opposed to numerous independent options; but they don't: URIs are not supported by these protocols which limits the applicability and extensibility of those configuration protocols. (SIP implementation may also not have control of the configuration protocols, making extensions difficult to implement.) As a SIP mechanism, UAs use REGISTER and thus the proxy can learn their compression and other capabilities. To learn about the proxy, the UA can use the OPTIONS method to inquire the proxy; the Max-Forwards: header may be used to "direct" the message to a particular (the first-hop) proxy. A further remark was made on the use of TLS in conjunction with this: when setting up a TLS connection, encryption as well as compression algortihms are negotiated; this should also be considered in a revised draft. From the discussion, a workable solution seems possible and the draft authors are asked to flesh out more details on how this is supposed to work. There is another question on whether or not this is a SIP WG item or if this is much broader in scope (i.e. configuration in general) and should be looked at somewhere else in the IETF. Whatever the approach will be, this does not affect the rest of the draft. Referrals from SIPPING (chairs) The SIPPING WG has done requirements work in a number of areas and has identified various places where SIP extensions are required and where the requirements work has matured. The work items discussed for taking in in the SIP WG were: * Content indirection: referring to a piece of information by means of a URL rather than including the information itself in a message. It was agreed to accept Content Indirection as a work item and adopt draft-olson-sip-content-indirect-mech-00.txt as basis for future work. * Join: A UA's pushing itself into an ongoing call thus turning it into a three-way conference (e.g. to implement single line extensions); note that this is different from joining an ongoing conference. This work item was adopted for the SIP WG. * IEPREP: since there are no firm requirements available, this work item cannot be taken up right now. The was also a brief discussion on SIP requirements for hearing-impaired: requirements have been done in the SIPPING WG and a design team is working on some mechanisms. But the scope is not yet clearly defined, so it is too early to consider this as SIP WG item. At least a reasonable Internet Draft is needed to go for the next step. An a-hoc group meeting on this subject was announced, the agenda being to which pieces are to be worked out next. Future Work Planning (chairs) The general idea is to move RFC 3261 to Draft Standard. Besides this master plan, there are a number of other work items on the plate to be moved through the process -- and typically new work items keep coming around. Another important issue is the migration from IPv4 to IPv6 and interworking between the two; a charter item needs to be defined for this. List discussion, ideas, drafts, etc. on this subject are solicited. It was found that the NGTRANS WG also started looking into SIP; they prefer this being looked at by the SIP community. The work may involve the SIPPING WG for some requirements as well as MMUSIC for negotiation. It was decided to start the discussion on the SIPPING list. Furthermore, an implementers guide was suggested; a work item also belonging to SIPPING. Finally, some discussion the state and cookies drafts came up. People were not sure whether or not those were really needed. ITU and 3GPP had expressed some need; other people felt they might use those mechanisms if available but do something different if not. One of the core issues with state/cookies is that the requirements have never been clearly defined -- and hence it is hard to devise (potentially cleaner) alternative mechanisms. This motivated the idea to push the work back to the SIPPING WG to develop a clear requirements spec. A deadline shall be set and, if by then no requirements have been defined, the work may as well be disappear altogether. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Aug 18 05:43:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22290 for ; Sun, 18 Aug 2002 05:43:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04458 for sip-archive@odin.ietf.org; Sun, 18 Aug 2002 05:44:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03541; Sun, 18 Aug 2002 05:12:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03510 for ; Sun, 18 Aug 2002 05:12:01 -0400 (EDT) Received: from bugs.cs.nthu.edu.tw (bugs.cs.nthu.edu.tw [140.114.79.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21981 for ; Sun, 18 Aug 2002 05:10:38 -0400 (EDT) Received: from localhost (utero@localhost) by bugs.cs.nthu.edu.tw (8.11.6/8.11.6) with ESMTP id g7J1Sqs24147; Mon, 19 Aug 2002 09:28:52 +0800 Date: Mon, 19 Aug 2002 09:28:52 +0800 (CST) From: Anthony Liu To: jh@lohi.eng.song.fi cc: sip@ietf.org Subject: Re: [Sip] SIP Server Roaming Problem In-Reply-To: <15708.59441.377218.613090@harjus.eng.song.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On Fri, 16 Aug 2002 jh@lohi.eng.song.fi wrote: > Anthony Liu writes: > > > If this MN happens to move into a foreign network that wishes any > > MN in it contacting its SIP server instead of the one in home network, > > do we have a mechanism for this? > > if you talk about MN that uses the 3g system, then there is no choice > whatsoever. the MN is in the walled garden as defined by the guardians > of the garden. > > -- juha > First, thanks for your reply, juha, MN in 3G system is ineed a situation I am considering. However, I do not think this is a limited question. For example, we have some complany providing 802.11 Internet access here in Taiwan and I think in the future, if SIP is so popular that every computer and every cellular has it built in, then this would become a question. As you said, in 3G systems, there is no choice. But how can a MN (maybe subscribed to some 802.11 service) change its presence on Internet (SIP location) to a cellular network it is roaming to without connection lost? (Since it will be using a proxy mode SIP server in a 3G system.) Is there a solution for this? Anthony _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Aug 18 07:04:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23243 for ; Sun, 18 Aug 2002 07:04:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07249 for sip-archive@odin.ietf.org; Sun, 18 Aug 2002 07:05:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06481; Sun, 18 Aug 2002 06:50:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06450 for ; Sun, 18 Aug 2002 06:49:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23064 for ; Sun, 18 Aug 2002 06:48:35 -0400 (EDT) Received: from dwillis9 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g7IAnV323869; Sun, 18 Aug 2002 05:49:31 -0500 Message-ID: <003501c246a4$f80ede20$1a02a8c0@dwillis9> From: "Dean Willis" To: Cc: , , References: <00ef01c23cb3$619da890$eb036e3f@TXDWILLIS2> Date: Sun, 18 Aug 2002 05:49:45 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Quick WGLC, Service Route Discovery draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I asked everybody to take a look at the Service Route Discovery draft on August 5. http://search.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-00.txt Since then, I've gotten one comment, from Adam Roach: --- Section 5: Service-Route = "Service-Route" HCOLON p-sr-value *( COMMA p-sr-value) p-sr-value = name-addr *( SEMI rr-param ) Probably should be sr-value, instead of p-sr-value. --- which is something I failed to catch when ripping out the P-headerishness. I thought I had already issued a formal WGLC August 7, but apparently I left said call sitting in the drafts folder on my home PC. Bad me. Remember, this draft had already gone through the working group as a P-. So, I'd like to request a quick working group last call. If you have issues (other than the above), get them to me no later than 21Aug. If there are issues, we'll of course hold things up and fix them. If at all possible, I'd like to send this to IETF Last Call by 22 Aug. Of coure, issues can be raised during IETF last call too . . . Thanks, -- 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 daemon@optimus.ietf.org Sun Aug 18 18:28:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05240 for ; Sun, 18 Aug 2002 18:28:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01060 for sip-archive@odin.ietf.org; Sun, 18 Aug 2002 18:29:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29928; Sun, 18 Aug 2002 17:56:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29898 for ; Sun, 18 Aug 2002 17:56:11 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04365 for ; Sun, 18 Aug 2002 17:54:49 -0400 (EDT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H12005K07KS70@firewall.wcom.com> for sip@ietf.org; Sun, 18 Aug 2002 21:55:40 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H1200D017KSFW@pmismtp04.wcomnet.com>; Sun, 18 Aug 2002 21:55:40 +0000 (GMT) Received: from hsinnreich2 ([166.50.97.40]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H12004MX7KQF5@pmismtp04.wcomnet.com>; Sun, 18 Aug 2002 21:55:40 +0000 (GMT) Date: Sun, 18 Aug 2002 16:55:38 -0500 From: Henry Sinnreich Subject: RE: [Sip] SIP Server Roaming Problem In-reply-to: To: "'Anthony Liu'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Message-id: <000001c24701$fda91050$286132a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit See the mobility page at www.cs.columbia.edu/sip on the mobile Internet. There is also a page at Telcordia. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Anthony Liu > Sent: Sunday, August 18, 2002 8:29 PM > To: jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: Re: [Sip] SIP Server Roaming Problem > > > On Fri, 16 Aug 2002 jh@lohi.eng.song.fi wrote: > > > Anthony Liu writes: > > > > > If this MN happens to move into a foreign network that > wishes any > > > MN in it contacting its SIP server instead of the one in home > > network, > do we have a mechanism for this? > > > > if you talk about MN that uses the 3g system, then there is > no choice > > whatsoever. the MN is in the walled garden as defined by the > > guardians of the garden. > > > > -- juha > > > First, thanks for your reply, juha, > > MN in 3G system is ineed a situation I am considering. > However, I do not think this is a limited question. For > example, we have some complany providing 802.11 Internet > access here in Taiwan and I think in the future, if SIP is so > popular that every computer and every cellular has it built > in, then this would become a question. > > As you said, in 3G systems, there is no choice. But how > can a MN (maybe subscribed to some 802.11 service) > change its presence on Internet (SIP location) to a cellular > network it is roaming to without connection lost? (Since it > will be using a proxy mode SIP server in a 3G system.) > > Is there a solution for this? > > Anthony > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Mon Aug 19 05:10:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25813 for ; Mon, 19 Aug 2002 05:10:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA06936 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 05:11:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05890; Mon, 19 Aug 2002 04:56:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05852 for ; Mon, 19 Aug 2002 04:55:59 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25464 for ; Mon, 19 Aug 2002 04:54:35 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7J8s8l28302 for ; Mon, 19 Aug 2002 11:54:08 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 19 Aug 2002 11:55:56 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Aug 2002 11:55:56 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA13984; Mon, 19 Aug 2002 11:55:55 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id g7J9kXY08682; Mon, 19 Aug 2002 12:46:33 +0300 Subject: Proxy and OPTIONS (Re: [Sip] SIP Traceroute using Max-Forwards) Date: Sat, 17 Aug 2002 00:37:40 +0300 Message-ID: From: "Pessi Pekka (NRC/Helsinki)" To: Cc: "Sriram Parameswar" Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 19 Aug 2002 08:55:56.0274 (UTC) FILETIME=[3B090520:01C2475E] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sriram Parameswar writes: >Alternatively, a server receiving an OPTIONS request with a Max-Forwards >header field value of 0 MAY respond to the request regardless of the >Request-URI. This is of limited use for traceroute, as the proxy is not expected to return its own address in the response to OPTIONS. Of course, it can (and should, but not SHOULD or even MAY) include its address in Contact. Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 08:06:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29298 for ; Mon, 19 Aug 2002 08:06:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15240 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 08:07:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13918; Mon, 19 Aug 2002 07:38:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13889 for ; Mon, 19 Aug 2002 07:38:34 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28529 for ; Mon, 19 Aug 2002 07:37:10 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g7JBcVG27358; Mon, 19 Aug 2002 13:38:32 +0200 (MEST) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g7JBcVF17378; Mon, 19 Aug 2002 13:38:31 +0200 (MEST) Received: from mhpaba5c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id g7JBcUmQ008633; Mon, 19 Aug 2002 13:38:30 +0200 (MEST) From: "Steffen Fries" Organization: Siemens AG To: Vesa.Torvinen@lmf.ericsson.se, jundery@ubiquity.net Date: Mon, 19 Aug 2002 13:38:30 +0200 MIME-Version: 1.0 Reply-to: steffen.fries@siemens.com CC: sip@ietf.org Message-ID: <3D60F4D6.4369.83C26A@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Subject: [Sip] Question to SIP Enhanced Digest Authentication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, by reading through draft-undery-sip-auth-01.txtI saw that a Proxy-Authentication-Info is mentioned. Is this just a mistake (the header available in SIP is Proxy-Authorization-Info) or is this a new header to be introduced? How does the further proceeding of this draft look like? Steffen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 08:08:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29341 for ; Mon, 19 Aug 2002 08:08:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15285 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 08:10:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14254; Mon, 19 Aug 2002 07:51:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14223 for ; Mon, 19 Aug 2002 07:51:38 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28809 for ; Mon, 19 Aug 2002 07:50:14 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Aug 2002 11:51:48 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 19 Aug 2002 12:53:42 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE018C2425@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: Question to SIP Enhanced Digest Authentication Thread-Index: AcJHdT8Qcm5s3rAaRTy31NF3g1mWDQAANi5w From: "James Undery" To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA14224 Subject: [Sip] RE: Question to SIP Enhanced Digest Authentication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Proxy-Authentication-Info is tricky, it does appear in rfc2617, but doesn't work for SIP (i.e. It uses Authentication-Info syntax but multiple proxies are possible with in SIP no way to match to Proxy-Authenticate headers). This draft is now waiting for Security Area comment, the limited scope is now really just to patch rfc2617. James > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@mchp.siemens.de] > Sent: 19 August 2002 12:39 > To: Vesa.Torvinen@lmf.ericsson.se; James Undery > Cc: sip@ietf.org > Subject: Question to SIP Enhanced Digest Authentication > > > Hi, > > by reading through draft-undery-sip-auth-01.txtI saw that a > Proxy-Authentication-Info is mentioned. Is this just a mistake > (the header available in SIP is Proxy-Authorization-Info) or is > this a new header to be introduced? > > How does the further proceeding of this draft look like? > > Steffen > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 08:42:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00243 for ; Mon, 19 Aug 2002 08:42:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16915 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 08:43:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15865; Mon, 19 Aug 2002 08:26:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15838 for ; Mon, 19 Aug 2002 08:26:56 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29742 for ; Mon, 19 Aug 2002 08:25:31 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7JCd7f10826 for ; Mon, 19 Aug 2002 15:39:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 19 Aug 2002 15:26:53 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Aug 2002 15:26:53 +0300 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: Mon, 19 Aug 2002 15:26:53 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C204BC@esebe019.ntc.nokia.com> Thread-Topic: Bug in absolute-URI grammar Thread-Index: AcJHe7Mv7ka3OCNNSLibnvYigBRsWA== To: X-OriginalArrivalTime: 19 Aug 2002 12:26:53.0836 (UTC) FILETIME=[B387B4C0:01C2477B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA15839 Subject: [Sip] Bug in absolute-URI grammar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit srvr = [ [ userinfo "@" ] hostport ] should be srvr = [ [ userinfo ] hostport ] Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 09:58:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02115 for ; Mon, 19 Aug 2002 09:58:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20431 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 10:00:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19829; Mon, 19 Aug 2002 09:37:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19765 for ; Mon, 19 Aug 2002 09:37:52 -0400 (EDT) Received: from brixcorp2.brixnet.com ([63.122.27.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01629; Mon, 19 Aug 2002 09:36:29 -0400 (EDT) Received: by mail.brixnet.com with Internet Mail Service (5.5.2656.59) id ; Mon, 19 Aug 2002 09:37:16 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB01943FB9@mail.brixnet.com> From: "Pyrik, Dan" To: "'Sean Olson'" , Arjun Roychowdhury , Sriram Parameswar Cc: "Naylor, Bob" , "Pyrik, Dan" , "Hedayat, Kaynam" , "Venna, Nagarjuna" , "'Jesske, R'" , sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] SIP Traceroute using Max-Forwards Date: Mon, 19 Aug 2002 09:37:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the information. The "SIP traceroute" application is meant to be more of a diagnostic tool, and perform the following: 1. record the path taken by the SIP messages. If there are multiple paths taken, that is fine. The application will tell us what the various paths are. 2. perform some timing on the responses of the proxies/endpoint. 3. record the capabilities of the proxies in the path(s) It looks like it will be able to do most of the above, with the exception of recording the addresses of proxies that do not support record-route. Thanks for all the help! Dan Pyrik Brix Networks -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Friday, August 16, 2002 2:31 PM To: Arjun Roychowdhury; Sriram Parameswar Cc: bnaylor@Brixnet.com; dpyrik@Brixnet.com; khedayat@Brixnet.com; nvenna@Brixnet.com; 'Jesske, R'; sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] SIP Traceroute using Max-Forwards --- Arjun Roychowdhury wrote: > To address the remaining open question: > > How do you figure out the address of the entity that > was the last node ? > In typical ICMP, the entity that receives > TTL sets to 0, sets its own IP address in the ICMP > response. However ,in > the case of SIP , the Via header in > the response will contain the address of the > previous hop (x-1) entity not > the one that responded (x). I think there may be some confusion here. The Via: headers will provide no information to the originator of the OPTIONS request as these are consumed in the reverse path. In fact, there is no way in the base SIP specification to get the ICMP traceroute behavior you seek. The closest approximation would be to examine the Record-Route: headers in an INVITE response. If you read the text of RFC3261 carefully: This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values You see that what you get is not the identity of the servers along the path, but rather their capabilities. > Again, the other thing is that in ICMP traceroute , > there is no absolute > guarantee that the next iteration will trace the > same path > as the previous path. That does not seem to be a > stumbling block in SIP > ->t o help solve this problem, am I correct in > saying > that Dan has to implement the source routing > record-route to ensure that > subsequent paths follow the previous path-set ? I guess the real question is what are you trying to accomplish with this "traceoute" behaviour. With stateless proxies in the path, it is quite likely that subsequent OPTIONS will take different paths. This is a good thing. You can, of course, send an OPTIONS within a dialog coupled with record-route to get more deterministic behavior, but again, loose routing makes no guarantees here. If you want to understand the capabilities of the servers that would be involved in procesing a dialog, OPTIONS has everything you need. If you want to diagnose a network failure and pinpoint the source of the failure, OPTIONS is somewhat lacking. > > It is also possible that if you send an OPTIONS the > entity that responds > with 200OK embeds its address in some place in the > SDP which > could account for reachability -> but then this is > not standard and no > process has been defined for it (to my knowledge) in > which > case you dont need to "go one hop ahead" to arrive > at the address of the > previous node. This is a possibility, but non-standard as you mention. It might be useful to publish an informational on this topic which describes the SDP usage you mention. Regards, Sean Olson Microsoft __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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 daemon@optimus.ietf.org Mon Aug 19 11:03:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04384 for ; Mon, 19 Aug 2002 11:03:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24327 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 11:04:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22903; Mon, 19 Aug 2002 10:41:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22839 for ; Mon, 19 Aug 2002 10:41:21 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03475; Mon, 19 Aug 2002 10:39:59 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id KAA18361; Mon, 19 Aug 2002 10:40:09 -0400 (EDT) Subject: RE: [Sip] SIP Traceroute using Max-Forwards To: "Pyrik, Dan" Cc: "'Sean Olson'" , Arjun Roychowdhury , Sriram Parameswar , "Naylor, Bob" , "Pyrik, Dan" , "Hedayat, Kaynam" , "Venna, Nagarjuna" , "'Jesske, R'" , sip@ietf.org, sip-admin@ietf.org Date: Mon, 19 Aug 2002 10:40:08 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 08/19/2002 10:40:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org How will this work when CPL scripts and caller preferen ce systems are common? "Pyrik, Dan" @ietf.org on 08/19/2002 09:37:14 AM Sent by: sip-admin@ietf.org To: "'Sean Olson'" , Arjun Roychowdhury , Sriram Parameswar cc: "Naylor, Bob" , "Pyrik, Dan" , "Hedayat, Kaynam" , "Venna, Nagarjuna" , "'Jesske, R'" , sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] SIP Traceroute using Max-Forwards Thanks for the information. The "SIP traceroute" application is meant to be more of a diagnostic tool, and perform the following: 1. record the path taken by the SIP messages. If there are multiple paths taken, that is fine. The application will tell us what the various paths are. 2. perform some timing on the responses of the proxies/endpoint. 3. record the capabilities of the proxies in the path(s) It looks like it will be able to do most of the above, with the exception of recording the addresses of proxies that do not support record-route. Thanks for all the help! Dan Pyrik Brix Networks -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Friday, August 16, 2002 2:31 PM To: Arjun Roychowdhury; Sriram Parameswar Cc: bnaylor@Brixnet.com; dpyrik@Brixnet.com; khedayat@Brixnet.com; nvenna@Brixnet.com; 'Jesske, R'; sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] SIP Traceroute using Max-Forwards --- Arjun Roychowdhury wrote: > To address the remaining open question: > > How do you figure out the address of the entity that > was the last node ? > In typical ICMP, the entity that receives > TTL sets to 0, sets its own IP address in the ICMP > response. However ,in > the case of SIP , the Via header in > the response will contain the address of the > previous hop (x-1) entity not > the one that responded (x). I think there may be some confusion here. The Via: headers will provide no information to the originator of the OPTIONS request as these are consumed in the reverse path. In fact, there is no way in the base SIP specification to get the ICMP traceroute behavior you seek. The closest approximation would be to examine the Record-Route: headers in an INVITE response. If you read the text of RFC3261 carefully: This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values You see that what you get is not the identity of the servers along the path, but rather their capabilities. > Again, the other thing is that in ICMP traceroute , > there is no absolute > guarantee that the next iteration will trace the > same path > as the previous path. That does not seem to be a > stumbling block in SIP > ->t o help solve this problem, am I correct in > saying > that Dan has to implement the source routing > record-route to ensure that > subsequent paths follow the previous path-set ? I guess the real question is what are you trying to accomplish with this "traceoute" behaviour. With stateless proxies in the path, it is quite likely that subsequent OPTIONS will take different paths. This is a good thing. You can, of course, send an OPTIONS within a dialog coupled with record-route to get more deterministic behavior, but again, loose routing makes no guarantees here. If you want to understand the capabilities of the servers that would be involved in procesing a dialog, OPTIONS has everything you need. If you want to diagnose a network failure and pinpoint the source of the failure, OPTIONS is somewhat lacking. > > It is also possible that if you send an OPTIONS the > entity that responds > with 200OK embeds its address in some place in the > SDP which > could account for reachability -> but then this is > not standard and no > process has been defined for it (to my knowledge) in > which > case you dont need to "go one hop ahead" to arrive > at the address of the > previous node. This is a possibility, but non-standard as you mention. It might be useful to publish an informational on this topic which describes the SDP usage you mention. Regards, Sean Olson Microsoft __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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 daemon@optimus.ietf.org Mon Aug 19 12:31:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08362 for ; Mon, 19 Aug 2002 12:31:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00414 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 12:32:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28726; Mon, 19 Aug 2002 12:04:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28699 for ; Mon, 19 Aug 2002 12:04:57 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07190 for ; Mon, 19 Aug 2002 12:03:34 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g7JG4W332507 for ; Mon, 19 Aug 2002 11:04:32 -0500 From: "Dean Willis" To: Subject: RE: [Sip] SIP Traceroute using Max-Forwards Date: Mon, 19 Aug 2002 11:04:27 -0500 Message-ID: <006f01c2479a$185933b0$c30c0c42@TXDWILLIS2> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > If you want to diagnose a network failure and > pinpoint the source of the failure, OPTIONS is > somewhat lacking. If you want to diagnose a network failure and pinpoint the source of the failure, SIP is somewhat lacking. It's easily fixed in single oerator environments by adding some "Kilroy Was Here" type headers in responses. I think it would be a good exercise to look at the requirements for this sort of thing (over in SIPPING) and see if we can move towards a nice, safe, and secure way of solving the general class problem. -- 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 daemon@optimus.ietf.org Mon Aug 19 12:38:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08749 for ; Mon, 19 Aug 2002 12:38:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00755 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 12:39:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29513; Mon, 19 Aug 2002 12:21:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29455 for ; Mon, 19 Aug 2002 12:21:34 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07780 for ; Mon, 19 Aug 2002 12:20:10 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7JGKNP15399 for ; Mon, 19 Aug 2002 11:20:24 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Aug 2002 11:20:09 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A63468@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: sip@ietf.org Date: Mon, 19 Aug 2002 11:20:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2479C.490A7E90" Subject: [Sip] draft-dean-phonectl-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2479C.490A7E90 Content-Type: text/plain Hi, What's the status of this work? Is this deemed outside the scope of SIP? Thanks, Sanjoy ------_=_NextPart_001_01C2479C.490A7E90 Content-Type: text/html draft-dean-phonectl-03.txt

Hi,

  What's the status of this work? Is this deemed outside the scope of SIP?

Thanks,
Sanjoy

------_=_NextPart_001_01C2479C.490A7E90-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 13:25:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10298 for ; Mon, 19 Aug 2002 13:25:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02646 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 13:26:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02129; Mon, 19 Aug 2002 13:06:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02102 for ; Mon, 19 Aug 2002 13:06:51 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09651 for ; Mon, 19 Aug 2002 13:05:28 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id NAA14303; Mon, 19 Aug 2002 13:06:09 -0400 (EDT) Subject: RE: [Sip] SIP Traceroute using Max-Forwards To: "Dean Willis" Cc: Date: Mon, 19 Aug 2002 13:06:08 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 08/19/2002 01:06: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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >I think it would be a good exercise to look at >the requirements for this sort of thing (over in >SIPPING) and see if we can move towards a nice, >safe, and secure way of solving the general class >problem. I'm wondering just how the general class of problem here is relevant to SIP in itself. The route among proxies is going to be selected at the application level by some combination of systems of which CPL and user preferences are early representatives. Just what could SIP supply in this application domain beyond the Kilroy-type headers described previously. Certainly the selection of headers to exercise various aspects of the application goes far beyond anything that could profitably be discussed in SIPPING. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 17:00:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15679 for ; Mon, 19 Aug 2002 17:00:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15658 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 17:01:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14382; Mon, 19 Aug 2002 16:40:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14352 for ; Mon, 19 Aug 2002 16:39:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15162 for ; Mon, 19 Aug 2002 16:38:34 -0400 (EDT) Received: from softarmor.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g7JKdV301604; Mon, 19 Aug 2002 15:39:31 -0500 Message-ID: <3D61577C.8050207@softarmor.com> Date: Mon, 19 Aug 2002 15:39:24 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom_Gray@mitel.com, sip@ietf.org Subject: Re: [Sip] SIP Traceroute using Max-Forwards References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tom_Gray@mitel.com wrote: > > >>I think it would be a good exercise to look at >>the requirements for this sort of thing (over in >>SIPPING) and see if we can move towards a nice, >>safe, and secure way of solving the general class >>problem. >> >> > >I'm wondering just how the general class of problem here is relevant to SIP >in itself. The route among proxies is going to be selected at the >application level by some combination of systems of which CPL and user >preferences are early representatives. Just what could SIP supply in this >application domain beyond the Kilroy-type headers described previously. >Certainly the selection of headers to exercise various aspects of the >application goes far beyond anything that could profitably be discussed in >SIPPING. > > I suspect even standardized kilroys would be useful. Many questions abound -- for example, what are the security issues, when many operators insist that completely hiding their topologies from discovery is a critical security function? Can the kilroys-type-headers be spoofed? How do you debug routing problems that span multiple operator environments? How do you poliely ask for the service nodes to add headers? How do you insist? -- 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 daemon@optimus.ietf.org Mon Aug 19 17:20:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16113 for ; Mon, 19 Aug 2002 17:20:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16348 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 17:22:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14663; Mon, 19 Aug 2002 16:52:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14602 for ; Mon, 19 Aug 2002 16:52:06 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15568; Mon, 19 Aug 2002 16:50:43 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7JKpSh06242; Mon, 19 Aug 2002 16:51:28 -0400 (EDT) To: Dean Willis Cc: sip@ietf.org, sip-admin@ietf.org, Tom_Gray@mitel.com Subject: Re: [Sip] SIP Traceroute using Max-Forwards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Mon, 19 Aug 2002 16:51:26 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/19/2002 04:49:32 PM, Serialize complete at 08/19/2002 04:49:32 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Taking the standard Killroy header forward, if you are planning to address a more general scope, probably another option may be to defined an XML body with tags where different servers could insert one or more parameters. eg. a.b.c.d c.d.e.f 75 The amount of information inserted could vary depending on what the servers want to insert as well as the minimal/maximal information requested by the original sender. The tags could be well defined (at least a subset) to specify a minimum profile. I am not sure if the above would be considered an overkill -> comments welcome. If operators decide not to provide information, well, then its their prereogative. This defines a mechanism to share 'characteristics' in a well defined way. I would also note that 'capability discovery' or 'path discovery' has an assumption that nodes participating will contribute information. Its similar to saying 'will traceroute work if a firewall blocks ICMP ? ' -> It will not - because the network layout decided so. I am not sure if these concerns need to be intertwined with specifying a mechanism. -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Dean Willis Sent by: sip-admin@ietf.org 08/19/2002 04:39 PM To: Tom_Gray@mitel.com, sip@ietf.org cc: Subject: Re: [Sip] SIP Traceroute using Max-Forwards Tom_Gray@mitel.com wrote: > > >>I think it would be a good exercise to look at >>the requirements for this sort of thing (over in >>SIPPING) and see if we can move towards a nice, >>safe, and secure way of solving the general class >>problem. >> >> > >I'm wondering just how the general class of problem here is relevant to SIP >in itself. The route among proxies is going to be selected at the >application level by some combination of systems of which CPL and user >preferences are early representatives. Just what could SIP supply in this >application domain beyond the Kilroy-type headers described previously. >Certainly the selection of headers to exercise various aspects of the >application goes far beyond anything that could profitably be discussed in >SIPPING. > > I suspect even standardized kilroys would be useful. Many questions abound -- for example, what are the security issues, when many operators insist that completely hiding their topologies from discovery is a critical security function? Can the kilroys-type-headers be spoofed? How do you debug routing problems that span multiple operator environments? How do you poliely ask for the service nodes to add headers? How do you insist? -- 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Aug 19 17:42:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16412 for ; Mon, 19 Aug 2002 17:42:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17216 for sip-archive@odin.ietf.org; Mon, 19 Aug 2002 17:43:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16156; Mon, 19 Aug 2002 17:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16092 for ; Mon, 19 Aug 2002 17:15:19 -0400 (EDT) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15981 for ; Mon, 19 Aug 2002 17:13:55 -0400 (EDT) Message-ID: <20020819211516.94388.qmail@web11606.mail.yahoo.com> Received: from [131.107.3.85] by web11606.mail.yahoo.com via HTTP; Mon, 19 Aug 2002 14:15:16 PDT Date: Mon, 19 Aug 2002 14:15:16 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] SIP Traceroute using Max-Forwards To: Arjun Roychowdhury , Dean Willis Cc: sip@ietf.org, sip-admin@ietf.org, Tom_Gray@mitel.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think these concepts can be separated. (1) You want to convey the identity of the servers along the path. (2) You also want to convey the capabilities of those servers. (3) Finally you may want to convey various performance metrics (like load) about those servers. The first is probably best handled by a simple extension header introduced into requests. Traceroute: servername along with Require: traceroute The second is best handled by a combination of existing headers (Accept:, Accept-Language:, etc.) and possibly a new XML payload for OPTIONS. Make that multipart/mixed and throw in SDP(ng) for more information. The third is probably best handled out-of-band using something like SNMP. /sean --- Arjun Roychowdhury wrote: > Taking the standard Killroy header forward, if you > are planning to address > a more general scope, probably another option may > be to defined an XML body with tags where different > servers could insert > one or more parameters. > eg. > > a.b.c.d > > > c.d.e.f > 75 > > > The amount of information inserted could vary > depending on what the > servers want to insert as well as the > minimal/maximal information > requested by the original sender. The tags could be > well defined (at least > a subset) to specify a minimum profile. > > I am not sure if the above would be considered an > overkill -> comments > welcome. > > If operators decide not to provide information, > well, then its their > prereogative. This defines a mechanism to share > 'characteristics' > in a well defined way. > > I would also note that 'capability discovery' or > 'path discovery' has an > assumption that nodes participating will contribute > information. > Its similar to saying 'will traceroute work if a > firewall blocks ICMP ? ' > -> It will not - because the network layout decided > so. I am not > sure if these concerns need to be intertwined with > specifying a mechanism. > > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301-212-7860 (M): 240-997-0066 > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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 daemon@optimus.ietf.org Tue Aug 20 03:43:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06984 for ; Tue, 20 Aug 2002 03:43:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22807 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 03:44:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21160; Tue, 20 Aug 2002 03:18:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21128 for ; Tue, 20 Aug 2002 03:18:17 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06438 for ; Tue, 20 Aug 2002 03:16:53 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7K7UWf10611 for ; Tue, 20 Aug 2002 10:30:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 20 Aug 2002 10:18:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Aug 2002 10:18:16 +0300 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: Tue, 20 Aug 2002 10:18:15 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C204BF@esebe019.ntc.nokia.com> Thread-Topic: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt Thread-Index: AcJHuTfw0HAckDPySCO9VSVxLaD8TwAYB9Nw To: , X-OriginalArrivalTime: 20 Aug 2002 07:18:16.0431 (UTC) FILETIME=[C0B5AFF0:01C24819] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA21129 Subject: [Sip] RE: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Redirected to sip. I don't think this sentence needs to be there at all. UAs should be able to perform content indirection on any MIME type. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, August 19, 2002 10:42 PM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Re: > draft-olson-sip-content-indirect-mech-01.txt > > > Sean - one comment about your draft: > > "3.4 ... User-Agents supporting content indirection MUST > support content indirection of the application/sdp MIME type." > > IMHO this is a bad special case. It is very easy to imagine > wanting to support indirection for something like PIDF, while > not wanting to support it for SDP. While in general this > could be handled by altering the Accept header on a > message-by-message basis, it could be a problem for > formulating a response to OPTIONS. It isn't much of a burden > to require application/sdp to be explicitly specified if intended. > > Paul > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Aug 20 06:26:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09798 for ; Tue, 20 Aug 2002 06:26:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA00513 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 06:27:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28898; Tue, 20 Aug 2002 05:44:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28871 for ; Tue, 20 Aug 2002 05:44:55 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09190 for ; Tue, 20 Aug 2002 05:43:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7K9h4l27421 for ; Tue, 20 Aug 2002 12:43:04 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 20 Aug 2002 12:44:52 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Aug 2002 12:44:50 +0300 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: Tue, 20 Aug 2002 12:44:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C204C6@esebe019.ntc.nokia.com> Thread-Topic: Mandatory header changed in response Thread-Index: AcJILjiA51qIoASwRQ2jokcEGgsVDQ== To: X-OriginalArrivalTime: 20 Aug 2002 09:44:50.0945 (UTC) FILETIME=[3AA60710:01C2482E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA28872 Subject: [Sip] Mandatory header changed in response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Now that matching responses to requests is done using branch-id. How should the behaviour be when a mandatory header has been modified in the response? E.g. 1 REGISTER ... To: sip:hisham.khartabil@nokia.com Contact: sip:hisham.khartabil@pc.nokia.com ... 200 Ok To: sip:someonelese@nokia.com Contact: sip:hisham.khartabil@pc.nokia.com ... Do we accept that a binding has been created? E.g. 2 INVITE ... CSeq: 1 INVITE 200 ok ... CSeq: 15 INVITE This affects the local sequence number. Which one to store and use for requests within dialogs? Thanks, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Aug 20 06:30:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09891 for ; Tue, 20 Aug 2002 06:30:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA01177 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 06:31:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29963; Tue, 20 Aug 2002 06:05:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29938 for ; Tue, 20 Aug 2002 06:05:33 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09514 for ; Tue, 20 Aug 2002 06:04:10 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7KA4xrU011927; Tue, 20 Aug 2002 12:05:14 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.29]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7KA4ia9017984; Tue, 20 Aug 2002 13:04:44 +0300 (EET DST) Message-ID: <3D62143C.C7C99385@lmf.ericsson.se> Date: Tue, 20 Aug 2002 13:04:44 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Mandatory header changed in response References: <2038BCC78B1AD641891A0D1AE133DBB7C204C6@esebe019.ntc.nokia.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I would regard is as an implementation issue, ie you choose if you don't care about the changed header values, or if you discard the message etc. Regards, Christer Holmberg Ericsson Finland hisham.khartabil@nokia.com wrote: > Now that matching responses to requests is done using branch-id. How should the behaviour be when a mandatory header has been modified in the response? > > E.g. 1 > > REGISTER ... > To: sip:hisham.khartabil@nokia.com > Contact: sip:hisham.khartabil@pc.nokia.com > ... > > 200 Ok > To: sip:someonelese@nokia.com > Contact: sip:hisham.khartabil@pc.nokia.com > ... > > Do we accept that a binding has been created? > > E.g. 2 > > INVITE > ... > CSeq: 1 INVITE > > 200 ok > ... > CSeq: 15 INVITE > > This affects the local sequence number. Which one to store and use for requests within dialogs? > > Thanks, > Hisham > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Aug 20 08:43:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12124 for ; Tue, 20 Aug 2002 08:43:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07049 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 08:45:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05128; Tue, 20 Aug 2002 08:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07409 for ; Sun, 18 Aug 2002 07:22:21 -0400 (EDT) Received: from web13008.mail.yahoo.com (web13008.mail.yahoo.com [216.136.174.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23458 for ; Sun, 18 Aug 2002 07:20:57 -0400 (EDT) Message-ID: <20020818112219.31811.qmail@web13008.mail.yahoo.com> Received: from [61.144.250.10] by web13008.mail.yahoo.com via HTTP; Sun, 18 Aug 2002 04:22:19 PDT Date: Sun, 18 Aug 2002 04:22:19 -0700 (PDT) From: cheng ford To: prasanna@huawei.com Cc: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-334181247-1029669739=:31170" Subject: [Sip] How to respond if the request has no Call-ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --0-334181247-1029669739=:31170 Content-Type: text/plain; charset=us-ascii Dear All: According to my understanding, I think the server can discard such request, since there is no call id, even if response back, how can it match? I think for important header such as From, To , Call-Id, CSeq, Via; if missing any one of them, server should discard such request. Best regards! Yours: Jack Hi, According to RFC 3261 section 21.4.1 "The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field"." If a request comes without a Call-ID header field, what call-ID should the 400 response bear. The same issue is applicable for "To" "From" CSeq" headers also. Another issue is, if a request does not bear a "Via" header, where should the response go, if at all the UAS decides to respond. Thanks in advance for the responses, Regards, Prasanna --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-334181247-1029669739=:31170 Content-Type: text/html; charset=us-ascii

Dear All:

     According to my understanding, I think the server can discard such request,

since there is no call id, even if response back, how can it match? I think for

important header such as From, To , Call-Id, CSeq, Via; if missing any one of them,

server should discard such request.

     Best regards!

                                    Yours: Jack

 

 

Hi,
 According to RFC 3261 section 21.4.1
"The Reason-Phrase SHOULD identify the syntax problem in more detail, for
   example, "Missing Call-ID header field"."

If a request comes without a Call-ID header field, what call-ID should the
400 response bear.

The same issue is applicable for "To" "From" CSeq" headers also.

Another issue is, if a request does not bear a "Via" header, where should
the response go, if at all the UAS decides to respond.

Thanks in advance for the responses,
Regards,
Prasanna


Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-334181247-1029669739=:31170-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Aug 20 08:44:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12162 for ; Tue, 20 Aug 2002 08:44:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07064 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 08:45:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05123; Tue, 20 Aug 2002 08:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08101 for ; Sun, 18 Aug 2002 07:37:32 -0400 (EDT) Received: from web13007.mail.yahoo.com (web13007.mail.yahoo.com [216.136.174.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23624 for ; Sun, 18 Aug 2002 07:36:08 -0400 (EDT) Message-ID: <20020818113728.38025.qmail@web13007.mail.yahoo.com> Received: from [61.144.250.10] by web13007.mail.yahoo.com via HTTP; Sun, 18 Aug 2002 04:37:28 PDT Date: Sun, 18 Aug 2002 04:37:28 -0700 (PDT) From: chen jack To: sip@ietf.org Cc: prasanna@huawei.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1588640745-1029670648=:37044" Subject: [Sip] How to respond if the request has no Call-ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --0-1588640745-1029670648=:37044 Content-Type: text/plain; charset=us-ascii Hi All: I agree with Mr Jack's idea, if there is no call-id, the server can discard this request, server can think this request is an attcking message. it is better to discard it!! This is my idea, any suggestions are welcome!! Yours: Chen ================================================== Dear All: According to my understanding, I think the server can discard such request, since there is no call id, even if response back, how can it match? I think for important header such as From, To , Call-Id, CSeq, Via; if missing any one of them, server should discard such request. Best regards! Yours: Jack ============================================ Hi, According to RFC 3261 section 21.4.1 "The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field"." If a request comes without a Call-ID header field, what call-ID should the 400 response bear. The same issue is applicable for "To" "From" CSeq" headers also. Another issue is, if a request does not bear a "Via" header, where should the response go, if at all the UAS decides to respond. Thanks in advance for the responses, Regards, Prasanna --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-1588640745-1029670648=:37044 Content-Type: text/html; charset=us-ascii

Hi All:

     I agree with Mr Jack's idea, if there is no call-id, the server can discard

this request, server can think this request is an attcking message. it is better

to discard it!!

      This is my idea, any suggestions are welcome!!

                                             Yours: Chen

    

 

==================================================

Dear All:

     According to my understanding, I think the server can discard such request,

since there is no call id, even if response back, how can it match? I think for

important header such as From, To , Call-Id, CSeq, Via; if missing any one of them,

server should discard such request.

     Best regards!

                                    Yours: Jack

  

  

 

 

============================================ 

Hi,
 According to RFC 3261 section 21.4.1
"The Reason-Phrase SHOULD identify the syntax problem in more detail, for
   example, "Missing Call-ID header field"."

If a request comes without a Call-ID header field, what call-ID should the
400 response bear.

The same issue is applicable for "To" "From" CSeq" headers also.

Another issue is, if a request does not bear a "Via" header, where should
the response go, if at all the UAS decides to respond.

Thanks in advance for the responses,
Regards,
Prasanna


Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-1588640745-1029670648=:37044-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Aug 20 09:04:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12954 for ; Tue, 20 Aug 2002 09:04:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08419 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 09:05:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06930; Tue, 20 Aug 2002 08:41:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06904 for ; Tue, 20 Aug 2002 08:41:02 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12007 for ; Tue, 20 Aug 2002 08:39:36 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7KCrGf17737 for ; Tue, 20 Aug 2002 15:53:16 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 20 Aug 2002 15:40:59 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Aug 2002 15:40:59 +0300 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" Subject: RE: [Sip] Mandatory header changed in response Date: Tue, 20 Aug 2002 15:40:58 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C204D3@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Mandatory header changed in response Thread-Index: AcJIMSY4vjgzSqwWSly+kd0bUUu2AQAE8/GQ To: Cc: X-OriginalArrivalTime: 20 Aug 2002 12:40:59.0093 (UTC) FILETIME=[D5C17050:01C24846] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA06905 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The point is that its too late to discard since the transactions layer accepted it and moved to the next state, so no retransmissions. Its not an implementation issue when To-header gets changed in a 200 Ok for an REGISTER, for example. Or when CSeq gets changed in 200 OK for INVITE. What does Server Core do? /Hisham > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, August 20, 2002 1:05 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] Mandatory header changed in response > > > > Hi, > > I would regard is as an implementation issue, ie you choose > if you don't care about the changed header values, or if you > discard the message etc. > > Regards, > > Christer Holmberg > Ericsson Finland > > hisham.khartabil@nokia.com wrote: > > > Now that matching responses to requests is done using > branch-id. How should the behaviour be when a mandatory > header has been modified in the response? > > > > E.g. 1 > > > > REGISTER ... > > To: sip:hisham.khartabil@nokia.com > > Contact: sip:hisham.khartabil@pc.nokia.com > > ... > > > > 200 Ok > > To: sip:someonelese@nokia.com > > Contact: sip:hisham.khartabil@pc.nokia.com > > ... > > > > Do we accept that a binding has been created? > > > > E.g. 2 > > > > INVITE > > ... > > CSeq: 1 INVITE > > > > 200 ok > > ... > > CSeq: 15 INVITE > > > > This affects the local sequence number. Which one to store > and use for requests within dialogs? > > > > Thanks, > > Hisham > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 daemon@optimus.ietf.org Tue Aug 20 09:04:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12998 for ; Tue, 20 Aug 2002 09:04:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08437 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 09:06:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05638; Tue, 20 Aug 2002 08:25:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05601 for ; Tue, 20 Aug 2002 08:25:33 -0400 (EDT) Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11625 for ; Tue, 20 Aug 2002 08:24:07 -0400 (EDT) Message-Id: <200208201224.IAA11625@ietf.org> Received: (qmail 29989 invoked from network); 20 Aug 2002 12:43:00 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 20 Aug 2002 12:43:00 -0000 Date: Tue, 20 Aug 2002 20:32:23 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id IAA05603 Subject: [Sip] SIP session timer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi All, I'm reading draft-ietf-sip-session-timer-09.txt, and I meet a question in the draft. in Page 9 (7.1 Generating a Session Refresh Request), it mentions: "The value of the Min-SE header field present in a session refresh request MUST be the largest value amongst all Min-SE header field values returned in all 422 responses, or received in session refresh requests, on the same dialog, if a dialog has been established. If no dialog has been established, the Min-SE header field value is set to ~~~~~~~~~~~~~~~~~~~~~~~~~~~~Since the dialog has not been established, then what is "the same Call-ID" mentioned below the largest value amongst all Min-SE header field values returned in all 422 responses for an INVITE request with the same Call-ID. A ~~~~~~~~~~~~~~~~~~~~~~ comparing with other dialog's Call-ID? result of this rule is that the maximum value of the Min-SE is effectively "cleared" once the dialog is established, and from that point on, only the values from proxies known to be on the proxy path will end up being used." Thanks a lot to give an answer! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Aug 20 11:46:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17805 for ; Tue, 20 Aug 2002 11:46:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16612 for sip-archive@odin.ietf.org; Tue, 20 Aug 2002 11:47:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14160; Tue, 20 Aug 2002 11:03:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14131 for ; Tue, 20 Aug 2002 11:03:09 -0400 (EDT) Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16660 for ; Tue, 20 Aug 2002 11:01:44 -0400 (EDT) Received: from laptopeng3 ([207.113.13.1]) by tonnant.cnchost.com id LAA21988; Tue, 20 Aug 2002 11:02:58 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <006201c2485a$c6af50f0$1fe4b4cc@laptopeng3> From: "Medhavi Bhatia" To: , Cc: References: <2038BCC78B1AD641891A0D1AE133DBB7C204D3@esebe019.ntc.nokia.com> Subject: Re: [Sip] Mandatory header changed in response Date: Tue, 20 Aug 2002 11:03:22 -0400 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.50.4522.1200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The spec mentions that the UAS must match the headers in the response. That has to be done at the transaction layer of the UAS, before the response is accepted and delivered to the core. I guess the transaction layer description should be updated to reflect that... ----- Original Message ----- From: To: Cc: Sent: Tuesday, August 20, 2002 8:40 AM Subject: RE: [Sip] Mandatory header changed in response > The point is that its too late to discard since the transactions layer accepted it and moved to the next state, so no retransmissions. > > Its not an implementation issue when To-header gets changed in a 200 Ok for an REGISTER, for example. Or when CSeq gets changed in 200 OK for INVITE. What does Server Core do? > > /Hisham > > > -----Original Message----- > > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, August 20, 2002 1:05 PM > > To: Khartabil Hisham (NMP/Helsinki) > > Cc: sip@ietf.org > > Subject: Re: [Sip] Mandatory header changed in response > > > > > > > > Hi, > > > > I would regard is as an implementation issue, ie you choose > > if you don't care about the changed header values, or if you > > discard the message etc. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > hisham.khartabil@nokia.com wrote: > > > > > Now that matching responses to requests is done using > > branch-id. How should the behaviour be when a mandatory > > header has been modified in the response? > > > > > > E.g. 1 > > > > > > REGISTER ... > > > To: sip:hisham.khartabil@nokia.com > > > Contact: sip:hisham.khartabil@pc.nokia.com > > > ... > > > > > > 200 Ok > > > To: sip:someonelese@nokia.com > > > Contact: sip:hisham.khartabil@pc.nokia.com > > > ... > > > > > > Do we accept that a binding has been created? > > > > > > E.g. 2 > > > > > > INVITE > > > ... > > > CSeq: 1 INVITE > > > > > > 200 ok > > > ... > > > CSeq: 15 INVITE > > > > > > This affects the local sequence number. Which one to store > > and use for requests within dialogs? > > > > > > Thanks, > > > Hisham > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@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@optimus.ietf.org Wed Aug 21 12:32:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15382 for ; Wed, 21 Aug 2002 12:32:08 -0400 (EDT) Received: (from mailnull@localhost) by optimus.ietf.org (8.11.6/8.11.6) id g7LGX5Q25552 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 12:33:05 -0400 Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LGWGW25512; Wed, 21 Aug 2002 12:32:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LGQiW24835 for ; Wed, 21 Aug 2002 12:26:44 -0400 Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15206 for ; Wed, 21 Aug 2002 12:25:17 -0400 (EDT) Received: from 12-235-146-159.client.attbi.com (HELO BOB) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2002 16:26:40 -0000 Reply-To: From: "Sean Olson" To: "'Paul Kyzivat'" Cc: , Subject: RE: [Sip] RE: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt Date: Wed, 21 Aug 2002 09:26:46 -0700 Message-ID: <000a01c2492f$8b995e90$6401a8c0@BOB> 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.3416 In-Reply-To: <3D63BB22.1885D7A6@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 Importance: 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 Sounds reasonable. I will adjust the text accordingly. Thanks, Sean -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, August 21, 2002 9:09 AM To: seancolson@yahoo.com Cc: hisham.khartabil@nokia.com; sip@ietf.org Subject: Re: [Sip] RE: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt Sean, I think some specific wording may be appropriate. (Not the wording there now.) Before figuring out the precise wording, I'd like to see if there is rough agreement on intent. Here are some implications of the proposal that I think may need clarification: 1) The semantics of the Accept header are pretty clear. If one is present, then *only* the types listed are accepted. If none is present then the default is "Accept: application/sdp". I don't think this should change so that one type being present (e.g. message/external-body) implies another type being present (e.g. application/sdp). 2) a corollary to (1) is that to be useful, an Accept header containing message/external-body will also need to mention at least one other content type. 3) suppose A sends a request to B, and does not indicate it accepts message/external-body. It also doesn't use content indirection in its request. However B has a need to use content indirection in its response (perhaps because it is too large to return otherwise). Then B must return 415 Unsupported Media, with an Accept header containing both message/external-body and the content type to be returned indirectly. 4) when a server responds to an OPTIONS request, it is impossible for the response to accurately reflect what content types are accepted if that varies according to request type. Section 11.2 of 3261 says that the response code be the same as it would have been for an INVITE. The same probably needs to be true for other parts of the response. In particular, the Accept header should reflect what would be sent in a response to an INVITE. Paul Sean Olson wrote: > > The intent is to allow content indirection for any MIME type. The idea > is to define a baseline of support. This is similar to the requirement > that UAs support HTTP URIs. Without such a baseline, > there is no way to know a priori that the receiving party supports > content-indirection of the > application/sdp MIME type. No big issue except that it means an extra > round trip for negotiation. > > I wanted to define the behavior in the absence of any other Accept: > header value. And I wanted to avoid changing the fact that UAs don't > have to explicitly list application/sdp > as a supported Content-Type. However, I agree that this is a huge hack > and probably not > what most people want. > > Unless someone objects and feels we need to specify a base set of MIME > types that all content indirection implementations support, I will > remove this from the next version of the draft. > > Thanks for the comments, > Sean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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@optimus.ietf.org Wed Aug 21 12:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16520 for ; Wed, 21 Aug 2002 12:57:16 -0400 (EDT) Received: (from mailnull@localhost) by optimus.ietf.org (8.11.6/8.11.6) id g7LGwCv28059 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 12:58:12 -0400 Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LGuSW27755; Wed, 21 Aug 2002 12:56:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LGt3W27643 for ; Wed, 21 Aug 2002 12:55:03 -0400 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12824 for ; Wed, 21 Aug 2002 11:09:35 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7LFAZXG005884; Wed, 21 Aug 2002 11:10:35 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAP51010; Wed, 21 Aug 2002 11:15:12 -0400 (EDT) Message-ID: <3D63AD63.AF857EAC@cisco.com> Date: Wed, 21 Aug 2002 11:10:27 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB7C204BF@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.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: , Content-Transfer-Encoding: 7bit Hisham, Are you saying that if a user agent wishes to support content indirection for one purpose (say for presence notifications) that it must be prepared to support content indirection for all other kinds of content as well? That seems like a very bad thing. Content is used for different purposes, in a variety of contexts. It may require very different implementation techniques to handle these. In some UAs the code that processes the body for an INVITE may be entirely distinct from the code that processes the body for a NOTIFY. In a particular request, perhaps support for content indirection should support its use for any Content-Type that is accepted in that request. Then the Supports header can be tuned on a message-by-message basis. But that raises the question of what support to claim in an OPTIONS response. Paul hisham.khartabil@nokia.com wrote: > > Redirected to sip. > > I don't think this sentence needs to be there at all. UAs should be able to perform content indirection on any MIME type. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, August 19, 2002 10:42 PM > > To: sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] Re: > > draft-olson-sip-content-indirect-mech-01.txt > > > > > > Sean - one comment about your draft: > > > > "3.4 ... User-Agents supporting content indirection MUST > > support content indirection of the application/sdp MIME type." > > > > IMHO this is a bad special case. It is very easy to imagine > > wanting to support indirection for something like PIDF, while > > not wanting to support it for SDP. While in general this > > could be handled by altering the Accept header on a > > message-by-message basis, it could be a problem for > > formulating a response to OPTIONS. It isn't much of a burden > > to require application/sdp to be explicitly specified if intended. > > > > Paul > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@optimus.ietf.org Wed Aug 21 13:12:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17508 for ; Wed, 21 Aug 2002 13:12:49 -0400 (EDT) Received: (from mailnull@localhost) by optimus.ietf.org (8.11.6/8.11.6) id g7LHDki29268 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 13:13:46 -0400 Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LHCfW29179; Wed, 21 Aug 2002 13:12:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LH9xW29026 for ; Wed, 21 Aug 2002 13:09:59 -0400 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14780 for ; Wed, 21 Aug 2002 12:08:14 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7LG9DNS015177; Wed, 21 Aug 2002 12:09:13 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAP51651; Wed, 21 Aug 2002 12:13:51 -0400 (EDT) Message-ID: <3D63BB22.1885D7A6@cisco.com> Date: Wed, 21 Aug 2002 12:09:06 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: seancolson@yahoo.com CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] RE: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt References: <000301c248e7$d0b5dd20$6401a8c0@BOB> 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 Sean, I think some specific wording may be appropriate. (Not the wording there now.) Before figuring out the precise wording, I'd like to see if there is rough agreement on intent. Here are some implications of the proposal that I think may need clarification: 1) The semantics of the Accept header are pretty clear. If one is present, then *only* the types listed are accepted. If none is present then the default is "Accept: application/sdp". I don't think this should change so that one type being present (e.g. message/external-body) implies another type being present (e.g. application/sdp). 2) a corollary to (1) is that to be useful, an Accept header containing message/external-body will also need to mention at least one other content type. 3) suppose A sends a request to B, and does not indicate it accepts message/external-body. It also doesn't use content indirection in its request. However B has a need to use content indirection in its response (perhaps because it is too large to return otherwise). Then B must return 415 Unsupported Media, with an Accept header containing both message/external-body and the content type to be returned indirectly. 4) when a server responds to an OPTIONS request, it is impossible for the response to accurately reflect what content types are accepted if that varies according to request type. Section 11.2 of 3261 says that the response code be the same as it would have been for an INVITE. The same probably needs to be true for other parts of the response. In particular, the Accept header should reflect what would be sent in a response to an INVITE. Paul Sean Olson wrote: > > The intent is to allow content indirection for any MIME type. The idea > is to define a baseline of support. > This is similar to the requirement that UAs support HTTP URIs. Without > such a baseline, > there is no way to know a priori that the receiving party supports > content-indirection of the > application/sdp MIME type. No big issue except that it means an extra > round trip for negotiation. > > I wanted to define the behavior in the absence of any other Accept: > header value. > And I wanted to avoid changing the fact that UAs don't have to > explicitly list application/sdp > as a supported Content-Type. However, I agree that this is a huge hack > and probably not > what most people want. > > Unless someone objects and feels we need to specify a base set of MIME > types that all > content indirection implementations support, I will remove this from the > next version of the draft. > > Thanks for the comments, > Sean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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@optimus.ietf.org Wed Aug 21 13:28:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18287 for ; Wed, 21 Aug 2002 13:28:02 -0400 (EDT) Received: (from mailnull@localhost) by optimus.ietf.org (8.11.6/8.11.6) id g7LHSxT29602 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 13:28:59 -0400 Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LHSPW29595; Wed, 21 Aug 2002 13:28:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LHRFW29565 for ; Wed, 21 Aug 2002 13:27:15 -0400 Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18173 for ; Wed, 21 Aug 2002 13:25:47 -0400 (EDT) Message-ID: <20020821172710.50718.qmail@web11601.mail.yahoo.com> Received: from [131.107.3.78] by web11601.mail.yahoo.com via HTTP; Wed, 21 Aug 2002 10:27:10 PDT Date: Wed, 21 Aug 2002 10:27:10 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Re: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt To: Paul Kyzivat , hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <3D63AD63.AF857EAC@cisco.com> 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: , We should not do less with content indirection than we can do with the existing SIP mechanisms. That is, we cannot remove content negotiation just because you support content indirection. This is not a question of what MIME types you support over content indirection, but rather what MIME types you support in general. The two are meant to be orthogonal. /sean --- Paul Kyzivat wrote: > Hisham, > > Are you saying that if a user agent wishes to > support content indirection for one purpose (say for > presence notifications) that it must be prepared to > support content indirection for all other kinds of > content as well? > > That seems like a very bad thing. Content is used > for different purposes, in a variety of contexts. It > may require very different implementation techniques > to handle these. In some UAs the code that processes > the body for an INVITE may be entirely distinct from > the code that processes the body for a NOTIFY. > > In a particular request, perhaps support for content > indirection should support its use for any > Content-Type that is accepted in that request. Then > the Supports header can be tuned on a > message-by-message basis. But that raises the > question of what support to claim in an OPTIONS > response. > > Paul > > hisham.khartabil@nokia.com wrote: > > > > Redirected to sip. > > > > I don't think this sentence needs to be there at > all. UAs should be able to perform content > indirection on any MIME type. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Paul Kyzivat > [mailto:pkyzivat@cisco.com] > > > Sent: Monday, August 19, 2002 10:42 PM > > > To: sip-implementors@cs.columbia.edu > > > Subject: [Sip-implementors] Re: > > > draft-olson-sip-content-indirect-mech-01.txt > > > > > > > > > Sean - one comment about your draft: > > > > > > "3.4 ... User-Agents supporting content > indirection MUST > > > support content indirection of the > application/sdp MIME type." > > > > > > IMHO this is a bad special case. It is very easy > to imagine > > > wanting to support indirection for something > like PIDF, while > > > not wanting to support it for SDP. While in > general this > > > could be handled by altering the Accept header > on a > > > message-by-message basis, it could be a problem > for > > > formulating a response to OPTIONS. It isn't much > of a burden > > > to require application/sdp to be explicitly > specified if intended. > > > > > > Paul > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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@optimus.ietf.org Wed Aug 21 15:53:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23081 for ; Wed, 21 Aug 2002 15:53:24 -0400 (EDT) Received: (from mailnull@localhost) by optimus.ietf.org (8.11.6/8.11.6) id g7LJsNm04536 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 15:54:23 -0400 Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LJf9W04115; Wed, 21 Aug 2002 15:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LJdVW04062 for ; Wed, 21 Aug 2002 15:39:31 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22723 for ; Wed, 21 Aug 2002 15:38:01 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7LJdPG26531 for ; Wed, 21 Aug 2002 15:39:25 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 14:39:25 -0500 Message-ID: <4440C8087B6E284287E9B1AE089BA08C0DBAD8@il0015exch002u.ih.lucent.com> From: "Ejzak, Richard P (Richard)" To: "'christer.holmberg@lmf.ericsson.se'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Wed, 21 Aug 2002 14:39:24 -0500 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: , Christer, I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date. (That explains the unusual format of the attached copy of your email on July 3 from the sip archive.) I am very confused by this discussion. Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media? According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold). And a UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold". (Essentially the same semantics are described in the manyfolks draft.) I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft. The text in question is: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream. However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)." Note that this is the only text I could find anywhere that couples the meaning of 180 with the state of the UAS media. Here is some other relevant text from various documents. First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup draft: "Accordingly, we have amended this text in 7.2.6 and 8.2.3 to reintroduce the 183 response code as the code that should be sent when locally-generated ringtone is undesirable or inappropriate." In describing the 180 ringing response, RFC 3261 says: "The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback." But manyfolks clearly says: "A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; ..." These mandatory preconditions can only be met via successful SDP negotiation. Just for the record, I completely agree with these three quotes. Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer. Some of us have been down this road before and there is no possibility of compromise here. Any procedure requiring the use of UPDATE immediately before (or possiblity during) 200 (INVITE) to take the UAS off hold is unlikely to be reliably acceptable to the end user (IMHO). Allow me to propose an alternative approach. Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media. If the UAC gets a 180, it MAY initiate local ringtone. If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive). If the UAC gets a 183, it stops any locally-generated ringtone. If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc. Just because the UAS is not on hold does not mean that it's sending any media. Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone. A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone. Any piggy-backing of SDP would just f! ollow existing rules. In more complex call progress scenarios, you could freely switch between these states. And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE). Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE. This approach eliminates coupling between the semantics of 180 and the state of the media, eliminates the need for final UPDATE before 200 (INVITE) in a common manyfolks scenario, is consistent with current text in all RFCs and most drafts (except the one quote and some related text from manyfolks), and easily supports complex call progress scenarios involving UAS endpoints with different in-band call progress media capabilities. The only other consideration I can think of is that this proposal seems to make it impossible to signal an ISUP alerting indication from a CPG within SIP once in-band call progress has been established (in either direction). [E.g., it precludes 180 after 183 when you don't want local ringtone but want in-band information instead. So how do you signal ISUP alerting after in-band call progress is established?] I propose that for this case (which I think is only needed for ISUP bridging), the ISUP alerting indication be optionally passed in a MIME attachment to a 183 response rather than a 180 response, to make it clear that the UAC should not generate local ringtone. [This minor change should go in the sip-isup draft.] Another way of looking at my proposal is that there would be no explicit SIP indication for "the UAS is being alerted; do not generate local ringtone". A SIP UAC would do nothing if it got such an indication anyway. If ISUP needs it in a bridging scenario, the ISUP MIME attachment to 183 satisfies that need. I would greatly appreciate any comments on my proposal. Regards, Richard Ejzak Lucent Technologies ------------------------------------------------------------------------------------------------------ email from Christer Holmberg dated July 3, 2002: Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has completed th! e first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland : end of email from Christer Holmberg dated July 3, 2002 ------------------------------------------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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@optimus.ietf.org Wed Aug 21 16:01:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23351 for ; Wed, 21 Aug 2002 16:01:54 -0400 (EDT) Received: (from mailnull@localhost) by optimus.ietf.org (8.11.6/8.11.6) id g7LK2rG05382 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 16:02:53 -0400 Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LK2LW05366; Wed, 21 Aug 2002 16:02:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LK1vW05348 for ; Wed, 21 Aug 2002 16:01:57 -0400 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23286 for ; Wed, 21 Aug 2002 16:00:28 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7LK1R3S022272; Wed, 21 Aug 2002 16:01:28 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAP53750; Wed, 21 Aug 2002 16:06:05 -0400 (EDT) Message-ID: <3D63F190.1F0420F9@cisco.com> Date: Wed, 21 Aug 2002 16:01:20 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Re: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt References: <20020821172710.50718.qmail@web11601.mail.yahoo.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 I generally agree. But there is another aspect that isn't discussed much: In the real world the support of content types is related to the context in which they are used. So I may support application/sdp in an INVITE, but not in a MESSAGE. And even within an INVITE, I can support application/sdp with content disposition of "session" but not with content disposition of "render". We don't have good ways to express these restrictions, or even to report that they have been violated. Paul Sean Olson wrote: > > We should not do less with content indirection > than we can do with the existing SIP mechanisms. > That is, we cannot remove content negotiation > just because you support content indirection. > > This is not a question of what MIME types you > support over content indirection, but rather what > MIME types you support in general. The two are meant > to be orthogonal. > > /sean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 21 16:23:43 2002 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 QAA24348 for ; Wed, 21 Aug 2002 16:23:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7LKOgV06154 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 16:24:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LKNOW06067; Wed, 21 Aug 2002 16:23:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LKMZW06028 for ; Wed, 21 Aug 2002 16:22:35 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24266 for ; Wed, 21 Aug 2002 16:21:05 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7LKMJRb012009; Wed, 21 Aug 2002 22:22:19 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7LKMHa9001685; Wed, 21 Aug 2002 23:22:17 +0300 (EET DST) Message-ID: <3D63F679.206A9797@lmf.ericsson.se> Date: Wed, 21 Aug 2002 23:22:17 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" CC: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: Re: [Sip] Local vs Remote ringback on 180 References: <4440C8087B6E284287E9B1AE089BA08C0DBAD8@il0015exch002u.ih.lucent.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id g7LKMZW06029 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 Richard, >I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date. (That explains the unusual >format of the attached copy of your email on July 3 from the sip archive.) > >I am very confused by this discussion. Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media? >According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold). And a >UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold". (Essentially >the same semantics are described in the manyfolks draft.) [CHH] First, the conclusion you have copied into this mail was sent BEFORE the latest discussion, where a slightly different solution was found. One difference now is that the generating of local ringback is NOT coupled to the media state - 180 now indicates that no early media is sent, so the UAC may generate local ringback no matter the media at the same time. 183 indicates that early media MAY be sent, but the UAC is recommended not to generate local ringback even if early media is sent or not. > I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft. The text in question is: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream. However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)." Note that this is the only text I could find anywhere that couples the meaning of 180 with the state of the UAS media. [CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv". However, the latest agreement DOES have some impacts on the manyfolks draft. The draft currently specifies that 180 is sent when the caller has been alerted (when the resource reservation has been done), but if the UAS wants to send early media 183 shall be sent instead of 180 (the sending of the FIRST 183, when the INVITE has been received, remains unchanged). Jon, could you please comment this manyfolks issue? > Here is some other relevant text from various documents. First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup draft: "Accordingly, we have amended this text in 7.2.6 and 8.2.3 to reintroduce the 183 response code as the code that should be sent when locally-generated ringtone is undesirable or inappropriate." In describing the 180 ringing response, RFC 3261 says: "The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback." But manyfolks clearly says: "A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; ..." These mandatory preconditions can only be met via successful SDP negotiation. Just for the record, I completely agree with these three quotes. [CHH] Again, the first provisional response sent in manyfolks is 183, which means the UAS MAY send early media, and which means the UAC should NOT generate local ringback. Of course, if the resource reservation is not done when the first 183 is sent, no early media will be sent, and no local ringback will be generated - so the caller will NOT be "alerted". Or, did I missunderstand your question? > Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer. Some of us have been down this road before and there is no possibility of compromise here. Any procedure requiring the use of UPDATE immediately before (or possiblity during) 200 (INVITE) to take the UAS off hold is unlikely to be reliably acceptable to the end user (IMHO). [CHH] The agreement means that is IS possible to set up a "sendrecv" media state using a single offer/answer transaction, even if no early media is sent, which means it's not mandatory to first set the media state to "inactive", and then to "sendrecv" when the called party answers the phone. Of course, if either party (for whatever reason) wants the media state to be "inactive" until the call has been answered it can still be done, but the major change is that it's not mandatory anymore - again, since the media state does NOT affect the decission if, or if not, to generate local ringback. > Allow me to propose an alternative approach. Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media. If the UAC gets a 180, it MAY initiate local ringtone. If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive). If the UAC gets a 183, it stops any locally-generated ringtone. [CHH] That's IS what we just have agreed upon a few days ago :) > If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc. Just because the UAS is not on hold does not mean that it's sending any media. [CHH] Exactly. > Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone. A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone. [CHH] Yes. > Any piggy-backing of SDP would just follow existing rules. In more complex call progress scenarios, you could freely switch between these states. And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE). Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE. > This approach eliminates coupling between the semantics of 180 and the state of the media, eliminates the need for final UPDATE before 200 (INVITE) in a common manyfolks scenario, is consistent with current text in all RFCs and most drafts (except the one quote and some related text from manyfolks), and easily supports complex call progress scenarios involving UAS endpoints with different in-band call progress media capabilities. > The only other consideration I can think of is that this proposal seems to make it impossible to signal an ISUP alerting indication from a CPG within SIP once in-band call progress has been established (in either direction). [E.g., it precludes 180 after 183 when you don't want local ringtone but want in-band information instead. So how do you signal ISUP alerting after in-band call progress is established?] I propose that for this case (which I think is only needed for ISUP bridging), the ISUP alerting indication be optionally passed in a MIME attachment to a 183 response rather than a 180 response, to make it clear that the UAC should not generate local ringtone. [This minor change should go in the sip-isup draft.] > Another way of looking at my proposal is that there would be no explicit SIP indication for "the UAS is being alerted; do not generate local ringtone". A SIP UAC would do nothing if it got such an indication anyway. If ISUP needs it in a bridging scenario, the ISUP MIME attachment to 183 satisfies that need. > I would greatly appreciate any comments on my proposal. [CHH] The "indicator" you mention was one of the options in the latest discussion on this. I think you should read THAT thread, because - again - the "conclusion" of mine that you attached to your mail was from a previous discussion :) Regards, Christer Holmberg Ericsson Finland > > Regards, > Richard Ejzak > Lucent Technologies > > ------------------------------------------------------------------------------------------------------ > email from Christer Holmberg dated July 3, 2002: > > Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has completed ! th! > e first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland > > : end of email from Christer Holmberg dated July 3, 2002 > ------------------------------------------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 21 18:03:44 2002 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 SAA27330 for ; Wed, 21 Aug 2002 18:03:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7LM4ji11625 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 18:04:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LM4GW11616; Wed, 21 Aug 2002 18:04:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LM0QW11537 for ; Wed, 21 Aug 2002 18:00:26 -0400 Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27247 for ; Wed, 21 Aug 2002 17:58:55 -0400 (EDT) Message-ID: <20020821220018.19055.qmail@web11607.mail.yahoo.com> Received: from [131.107.3.84] by web11607.mail.yahoo.com via HTTP; Wed, 21 Aug 2002 15:00:18 PDT Date: Wed, 21 Aug 2002 15:00:18 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Re: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt To: Paul Kyzivat Cc: sip@ietf.org In-Reply-To: <3D63F190.1F0420F9@cisco.com> 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 completely agree. We have a somewhat blunt tool which is Accept:. Should we invent something new? Perhaps. I don't think the content indirection draft is a good place to do this. The two problems are separable as I mentioned. If in the future we come up with something better than Accept: as it is today, then it should be trivial to make that work with content indirection. The problem you mention should probably be addressed in a separate I-D on capabilities/feature negotiation. This reminds me a lot of the SDPng stuff. For the time being, we can deal with the klunky Accept-X headers and in the future we could replace it with a more elegant solution perhaps along the lines of the feature set work that Jonathan has put into caller-prefs. /sean --- Paul Kyzivat wrote: > I generally agree. But there is another aspect that > isn't discussed much: > > In the real world the support of content types is > related to the context in which they are used. So I > may support application/sdp in an INVITE, but not in > a MESSAGE. And even within an INVITE, I can support > application/sdp with content disposition of > "session" but not with content disposition of > "render". > > We don't have good ways to express these > restrictions, or even to report that they have been > violated. > > Paul > > Sean Olson wrote: > > > > We should not do less with content indirection > > than we can do with the existing SIP mechanisms. > > That is, we cannot remove content negotiation > > just because you support content indirection. > > > > This is not a question of what MIME types you > > support over content indirection, but rather what > > MIME types you support in general. The two are > meant > > to be orthogonal. > > > > /sean > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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 Aug 21 18:27:28 2002 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 SAA27791 for ; Wed, 21 Aug 2002 18:27:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7LMSPD12076 for sip-archive@odin.ietf.org; Wed, 21 Aug 2002 18:28:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LMRGW12031; Wed, 21 Aug 2002 18:27:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LMOWW11982 for ; Wed, 21 Aug 2002 18:24:32 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27687 for ; Wed, 21 Aug 2002 18:23:02 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7LMOPd29437 for ; Wed, 21 Aug 2002 18:24:25 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 17:24:25 -0500 Message-ID: <4440C8087B6E284287E9B1AE089BA08C0DBAD9@il0015exch002u.ih.lucent.com> From: "Ejzak, Richard P (Richard)" To: "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Wed, 21 Aug 2002 17:24:24 -0500 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: , Christer, Thank you for your rapid response. I had in fact looked at some of the messages from the other threat you mentioned in the sipping archive, but did not understand the final conclusion until I read your email. With all the discussion about not having a general early media solution, I took away a different impression of Jon's final solution. I only have a couple of questions for you: You said "[CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv"." This was in response to a scenario described in manyfolks where a 183 exchange resulting in sendrecv media is followed by a 180. I am confused by your comment, since elsewhere you indicate that in this scenario the UAC would generate local ringtone. Did you mean to say that the 180 WOULD TRIGGER local ringtone? Or am I still hopelessly confused? And did you mean to imply that there is no change needed to the text I quoted from manyfolks? Or that this text needs to be changed as I suggested? I agree that the other text you reference from manyfolks also seems inconsistent with this recent decision. Regards, Richard Ejzak -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, August 21, 2002 3:22 PM To: Ejzak, Richard P (Richard) Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: Re: [Sip] Local vs Remote ringback on 180 Hi Richard, >I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date. (That explains the unusual >format of the attached copy of your email on July 3 from the sip archive.) > >I am very confused by this discussion. Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media? >According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold). And a >UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold". (Essentially >the same semantics are described in the manyfolks draft.) [CHH] First, the conclusion you have copied into this mail was sent BEFORE the latest discussion, where a slightly different solution was found. One difference now is that the generating of local ringback is NOT coupled to the media state - 180 now indicates that no early media is sent, so the UAC may generate local ringback no matter the media at the same time. 183 indicates that early media MAY be sent, but the UAC is recommended not to generate local ringback even if early media is sent or not. > I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft. The text in question is: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream. However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)." Note that this is the only text I could find anywhere that couples the meaning of 180 with the state of the UAS media. [CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv". However, the latest agreement DOES have some impacts on the manyfolks draft. The draft currently specifies that 180 is sent when the caller has been alerted (when the resource reservation has been done), but if the UAS wants to send early media 183 shall be sent instead of 180 (the sending of the FIRST 183, when the INVITE has been received, remains unchanged). Jon, could you please comment this manyfolks issue? > Here is some other relevant text from various documents. First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup draft: "Accordingly, we have amended this text in 7.2.6 and 8.2.3 to reintroduce the 183 response code as the code that should be sent when locally-generated ringtone is undesirable or inappropriate." In describing the 180 ringing response, RFC 3261 says: "The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback." But manyfolks clearly says: "A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; ..." These mandatory preconditions can only be met via successful SDP negotiation. Just for the record, I completely agree with these three quotes. [CHH] Again, the first provisional response sent in manyfolks is 183, which means the UAS MAY send early media, and which means the UAC should NOT generate local ringback. Of course, if the resource reservation is not done when the first 183 is sent, no early media will be sent, and no local ringback will be generated - so the caller will NOT be "alerted". Or, did I missunderstand your question? > Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer. Some of us have been down this road before and there is no possibility of compromise here. Any procedure requiring the use of UPDATE immediately before (or possiblity during) 200 (INVITE) to take the UAS off hold is unlikely to be reliably acceptable to the end user (IMHO). [CHH] The agreement means that is IS possible to set up a "sendrecv" media state using a single offer/answer transaction, even if no early media is sent, which means it's not mandatory to first set the media state to "inactive", and then to "sendrecv" when the called party answers the phone. Of course, if either party (for whatever reason) wants the media state to be "inactive" until the call has been answered it can still be done, but the major change is that it's not mandatory anymore - again, since the media state does NOT affect the decission if, or if not, to generate local ringback. > Allow me to propose an alternative approach. Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media. If the UAC gets a 180, it MAY initiate local ringtone. If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive). If the UAC gets a 183, it stops any locally-generated ringtone. [CHH] That's IS what we just have agreed upon a few days ago :) > If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc. Just because the UAS is not on hold does not mean that it's sending any media. [CHH] Exactly. > Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone. A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone. [CHH] Yes. > Any piggy-backing of SDP would just follow existing rules. In more complex call progress scenarios, you could freely switch between these states. And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE). Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE. > This approach eliminates coupling between the semantics of 180 and the state of the media, eliminates the need for final UPDATE before 200 (INVITE) in a common manyfolks scenario, is consistent with current text in all RFCs and most drafts (except the one quote and some related text from manyfolks), and easily supports complex call progress scenarios involving UAS endpoints with different in-band call progress media capabilities. > The only other consideration I can think of is that this proposal seems to make it impossible to signal an ISUP alerting indication from a CPG within SIP once in-band call progress has been established (in either direction). [E.g., it precludes 180 after 183 when you don't want local ringtone but want in-band information instead. So how do you signal ISUP alerting after in-band call progress is established?] I propose that for this case (which I think is only needed for ISUP bridging), the ISUP alerting indication be optionally passed in a MIME attachment to a 183 response rather than a 180 response, to make it clear that the UAC should not generate local ringtone. [This minor change should go in the sip-isup draft.] > Another way of looking at my proposal is that there would be no explicit SIP indication for "the UAS is being alerted; do not generate local ringtone". A SIP UAC would do nothing if it got such an indication anyway. If ISUP needs it in a bridging scenario, the ISUP MIME attachment to 183 satisfies that need. > I would greatly appreciate any comments on my proposal. [CHH] The "indicator" you mention was one of the options in the latest discussion on this. I think you should read THAT thread, because - again - the "conclusion" of mine that you attached to your mail was from a previous discussion :) Regards, Christer Holmberg Ericsson Finland > > Regards, > Richard Ejzak > Lucent Technologies > > ------------------------------------------------------------------------------------------------------ > email from Christer Holmberg dated July 3, 2002: > > Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has completed ! th! > e first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland > > : end of email from Christer Holmberg dated July 3, 2002 > ------------------------------------------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 00:46:26 2002 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 AAA05768 for ; Thu, 22 Aug 2002 00:46:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M4lTr26298 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 00:47:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M4kjW26276; Thu, 22 Aug 2002 00:46:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M4g4W26206 for ; Thu, 22 Aug 2002 00:42:04 -0400 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05678 for ; Thu, 22 Aug 2002 00:40:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7M4fOrU003345; Thu, 22 Aug 2002 06:41:29 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7M4fCa9006835; Thu, 22 Aug 2002 07:41:12 +0300 (EET DST) Message-ID: <3D646B68.7DCA5C00@lmf.ericsson.se> Date: Thu, 22 Aug 2002 07:41:12 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" CC: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: Re: [Sip] Local vs Remote ringback on 180 References: <4440C8087B6E284287E9B1AE089BA08C0DBAD9@il0015exch002u.ih.lucent.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id g7M4g4W26207 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 Richard, > Christer, > Thank you for your rapid response. I had in fact looked at some of the messages from the other threat you mentioned in the sipping archive, but did not understand the final conclusion until I read your email. With all the discussion about not having a general early media solution, I took away a different impression of Jon's final solution. [CHH] There still ARE issues (eg media clipping) related to early media, which will be described as part of a general solution. > I only have a couple of questions for you: > > You said "[CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv"." This was in response to a scenario described in manyfolks where a 183 exchange resulting in sendrecv media is followed by a 180. I am confused by your comment, since elsewhere you indicate that in this scenario the UAC would generate local ringtone. [CHH] Whoops, I guess I wrote something wrong. The 180 WOULD trigger local ringback, or course :) > Did you mean to say that the 180 WOULD TRIGGER local ringtone? [CHH] Yes. > Or am I still hopelessly confused? [CHH] Hopefully not :) > And did you mean to imply that there is no change needed to the text I quoted from manyfolks? Or that this text needs to be changed as I suggested? I agree that the other text you reference from manyfolks also seems inconsistent with this recent decision. [CHH] The change/add I talked about was that the UAS would, in case there may be early media send 183 (instead of 180) when the called party has been alerted. Your comment on manyfolks was on the FIRST 183 sent, right? Regards, Christer Holmberg Ericsson Finland > > > Regards, > > Richard Ejzak > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, August 21, 2002 3:22 PM > To: Ejzak, Richard P (Richard) > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: Re: [Sip] Local vs Remote ringback on 180 > > Hi Richard, > > >I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date. (That explains the unusual >format of the attached copy of your email on July 3 from the sip archive.) > > > >I am very confused by this discussion. Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media? >According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold). And a >UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold". (Essentially >the same semantics are described in the manyfolks draft.) > > [CHH] First, the conclusion you have copied into this mail was sent BEFORE the latest discussion, where a slightly different solution was found. One difference now is that the generating of local ringback is NOT coupled to the media state - 180 now indicates that no early media is sent, so the UAC may generate local ringback no matter the media at the same time. 183 indicates that early media MAY be sent, but the UAC is recommended not to generate local ringback even if early media is sent or not. > > > I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft. The text in question is: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream. However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)." Note that this is the only text I could find anywhere that couples the meaning of 180 with the state of the UAS media. > > [CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv". > > However, the latest agreement DOES have some impacts on the manyfolks draft. The draft currently specifies that 180 is sent when the caller has been alerted (when the resource reservation has been done), but if the UAS wants to send early media 183 shall be sent instead of 180 (the sending of the FIRST 183, when the INVITE has been received, remains unchanged). > > Jon, could you please comment this manyfolks issue? > > > Here is some other relevant text from various documents. First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup draft: "Accordingly, we have amended this text in 7.2.6 and 8.2.3 to reintroduce the 183 response code as the code that should be sent when locally-generated ringtone is undesirable or inappropriate." In describing the 180 ringing response, RFC 3261 says: "The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback." But manyfolks clearly says: "A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; ..." These mandatory preconditions can only be met via successful SDP negotiation. Just for the record, I completely agree with these three quotes. > > [CHH] Again, the first provisional response sent in manyfolks is 183, which means the UAS MAY send early media, and which means the UAC should NOT generate local ringback. Of course, if the resource reservation is not done when the first 183 is sent, no early media will be sent, and no local ringback will be generated - so the caller will NOT be "alerted". Or, did I missunderstand your question? > > > Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer. Some of us have been down this road before and there is no possibility of compromise here. Any procedure requiring the use of UPDATE immediately before (or possiblity during) 200 (INVITE) to take the UAS off hold is unlikely to be reliably acceptable to the end user (IMHO). > > [CHH] The agreement means that is IS possible to set up a "sendrecv" media state using a single offer/answer transaction, even if no early media is sent, which means it's not mandatory to first set the media state to "inactive", and then to "sendrecv" when the called party answers the phone. Of course, if either party (for whatever reason) wants the media state to be "inactive" until the call has been answered it can still be done, but the major change is that it's not mandatory anymore - again, since the media state does NOT affect the decission if, or if not, to generate local ringback. > > > Allow me to propose an alternative approach. Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media. If the UAC gets a 180, it MAY initiate local ringtone. If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive). If the UAC gets a 183, it stops any locally-generated ringtone. > > [CHH] That's IS what we just have agreed upon a few days ago :) > > > If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc. Just because the UAS is not on hold does not mean that it's sending any media. > > [CHH] Exactly. > > > Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone. A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone. > > [CHH] Yes. > > > Any piggy-backing of SDP would just follow existing rules. In more complex call progress scenarios, you could freely switch between these states. And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE). Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE. > > This approach eliminates coupling between the semantics of 180 and the state of the media, eliminates the need for final UPDATE before 200 (INVITE) in a common manyfolks scenario, is consistent with current text in all RFCs and most drafts (except the one quote and some related text from manyfolks), and easily supports complex call progress scenarios involving UAS endpoints with different in-band call progress media capabilities. > > The only other consideration I can think of is that this proposal seems to make it impossible to signal an ISUP alerting indication from a CPG within SIP once in-band call progress has been established (in either direction). [E.g., it precludes 180 after 183 when you don't want local ringtone but want in-band information instead. So how do you signal ISUP alerting after in-band call progress is established?] I propose that for this case (which I think is only needed for ISUP bridging), the ISUP alerting indication be optionally passed in a MIME attachment to a 183 response rather than a 180 response, to make it clear that the UAC should not generate local ringtone. [This minor change should go in the sip-isup draft.] > > Another way of looking at my proposal is that there would be no explicit SIP indication for "the UAS is being alerted; do not generate local ringtone". A SIP UAC would do nothing if it got such an indication anyway. If ISUP needs it in a bridging scenario, the ISUP MIME attachment to 183 satisfies that need. > > I would greatly appreciate any comments on my proposal. > > [CHH] The "indicator" you mention was one of the options in the latest discussion on this. I think you should read THAT thread, because - again - the "conclusion" of mine that you attached to your mail was from a previous discussion :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > Richard Ejzak > > Lucent Technologies > > > > ------------------------------------------------------------------------------------------------------ > > email from Christer Holmberg dated July 3, 2002: > > > > Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has complete! d ! > th! > > e first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland > > > > : end of email from Christer Holmberg dated July 3, 2002 > > ------------------------------------------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 02:38:08 2002 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 CAA16576 for ; Thu, 22 Aug 2002 02:38:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M6dCx06845 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 02:39:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M6bGW06811; Thu, 22 Aug 2002 02:37:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M6YnW06742 for ; Thu, 22 Aug 2002 02:34:49 -0400 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16472 for ; Thu, 22 Aug 2002 02:33:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7M6YeV24236 for ; Thu, 22 Aug 2002 09:34:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 Aug 2002 09:34:37 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 Aug 2002 09:34:37 +0300 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" Subject: RE: [Sip] Re: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt Date: Thu, 22 Aug 2002 09:34:37 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C204F0@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Re: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt Thread-Index: AcJJNPEGsV0SMs2OQa6mV/vyjKNTtgAcEMPg To: Cc: X-OriginalArrivalTime: 22 Aug 2002 06:34:37.0717 (UTC) FILETIME=[FCA92450:01C249A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id g7M6YnW06743 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 > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, August 21, 2002 6:10 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: sip@ietf.org > Subject: [Sip] Re: [Sip-implementors] Re: > draft-olson-sip-content-indirect-mech-01.txt > > > Hisham, > > Are you saying that if a user agent wishes to support content > indirection for one purpose (say for presence notifications) > that it must be prepared to support content indirection for > all other kinds of content as well? No, content-indirection support is just another MIME type. Your implementation can support message/external-body as well as application/sdp. If content-type: message/external-body is supported, then you go download the message. After you download, you examine the new content-type that you have now and make a decision on support for that MIME type then. /Hisham > > That seems like a very bad thing. Content is used for > different purposes, in a variety of contexts. It may require > very different implementation techniques to handle these. In > some UAs the code that processes the body for an INVITE may > be entirely distinct from the code that processes the body > for a NOTIFY. > > In a particular request, perhaps support for content > indirection should support its use for any Content-Type that > is accepted in that request. Then the Supports header can be > tuned on a message-by-message basis. But that raises the > question of what support to claim in an OPTIONS response. > > Paul > > hisham.khartabil@nokia.com wrote: > > > > Redirected to sip. > > > > I don't think this sentence needs to be there at all. UAs > should be able to perform content indirection on any MIME type. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, August 19, 2002 10:42 PM > > > To: sip-implementors@cs.columbia.edu > > > Subject: [Sip-implementors] Re: > > > draft-olson-sip-content-indirect-mech-01.txt > > > > > > > > > Sean - one comment about your draft: > > > > > > "3.4 ... User-Agents supporting content indirection MUST > > > support content indirection of the application/sdp MIME type." > > > > > > IMHO this is a bad special case. It is very easy to imagine > > > wanting to support indirection for something like PIDF, while > > > not wanting to support it for SDP. While in general this > > > could be handled by altering the Accept header on a > > > message-by-message basis, it could be a problem for > > > formulating a response to OPTIONS. It isn't much of a burden > > > to require application/sdp to be explicitly specified if intended. > > > > > > Paul > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Aug 22 04:27:51 2002 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 EAA18353 for ; Thu, 22 Aug 2002 04:27:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M8Sut11471 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 04:28:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M8SXW11444; Thu, 22 Aug 2002 04:28:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M8QoW11358 for ; Thu, 22 Aug 2002 04:26:50 -0400 Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18294 for ; Thu, 22 Aug 2002 04:25:14 -0400 (EDT) Message-Id: <200208220825.EAA18294@ietf.org> Received: (qmail 6858 invoked from network); 22 Aug 2002 03:17:40 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 22 Aug 2002 03:17:40 -0000 Date: Thu, 22 Aug 2002 11:7:6 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id g7M8QoW11359 Subject: [Sip] inbound & outbound 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, Can you give me the detailed difference between: 1) "inbound proxy" and "outbound proxy" 2) "inbound services" and "outbound services" Thanks a lot to give me an answer! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 10:38:41 2002 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 KAA27470 for ; Thu, 22 Aug 2002 10:38:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MEddS28831 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 10:39: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 g7MEcEo28753; Thu, 22 Aug 2002 10:38: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 g7MEaGo28689 for ; Thu, 22 Aug 2002 10:36:16 -0400 Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27281 for ; Thu, 22 Aug 2002 10:34:47 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H1900F011UFRI@siemenscomms.co.uk> for sip@ietf.org; Thu, 22 Aug 2002 15:35:03 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H1900FGC1TW5T@siemenscomms.co.uk>; Thu, 22 Aug 2002 15:34:44 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Aug 2002 15:35:14 +0100 Content-return: allowed Date: Thu, 22 Aug 2002 15:32:50 +0100 From: "Elwell, John" Subject: RE: [Sip] Local vs Remote ringback on 180 To: "'Ejzak, Richard P (Richard)'" , "'christer.holmberg@lmf.ericsson.se'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E73B@Beex50.siemenscomms.co.uk> 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 Richard, You wrote: > The only other consideration I can think of is that this > proposal seems to make it impossible to signal an ISUP > alerting indication from a CPG within SIP once in-band call > progress has been established (in either direction). [E.g., > it precludes 180 after 183 when you don't want local ringtone > but want in-band information instead. So how do you signal > ISUP alerting after in-band call progress is established?] I > propose that for this case (which I think is only needed for > ISUP bridging), the ISUP alerting indication be optionally > passed in a MIME attachment to a 183 response rather than a > 180 response, to make it clear that the UAC should not > generate local ringtone. [This minor change should go in the > sip-isup draft.] Similarly, it does not allow us to signal a QSIG ALERTING message accompanied by in-band tone or announcement. If it is signalled as 180, local ring-back tone might be applied and the remote tone or announcement lost. If it is signalled as 183, a QSIG UAC will map to PROGRESS rather than ALERTING, and this could have implications in the originating QSIG network or at the caller's equipment. Although we could solve this QSIG-SIP-QSIG scenario by tunnelling QSIG in MIME, this solution will not work for QSIG-SIP-ISUP and ISUP-SIP-QSIG scenarios. I made this point a few days ago on the SIPPING thread and have not had an answer. John -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 10:54:57 2002 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 KAA28002 for ; Thu, 22 Aug 2002 10:54:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MEtsF29462 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 10:55:54 -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 g7MEtIo29449; Thu, 22 Aug 2002 10:55:18 -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 g7MEsto29427 for ; Thu, 22 Aug 2002 10:54:55 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27982 for ; Thu, 22 Aug 2002 10:53:27 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7MEspn25879 for ; Thu, 22 Aug 2002 10:54:51 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 09:54:51 -0500 Message-ID: <4440C8087B6E284287E9B1AE089BA08C0DBADA@il0015exch002u.ih.lucent.com> From: "Ejzak, Richard P (Richard)" To: "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 22 Aug 2002 09:54:45 -0500 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: , Christer, Regarding manyfolks (07), I actually have several issues/comments; most of them in section 12.1 on page 18, referencing figure 2. I feel compelled to enumerate them since my original comment was NOT with reference to the first 183. 1) Without mandatory preconditions, it should be possible for the UAS to return a 180 without SDP in response to the INVITE, after which the UAC MAY generate local ringtone. The offer/answer rules in 100rel clearly state that "If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by the UAC)." So the answer may be in the 2nd or 3rd provisional response, or even wait until 200 (INVITE). Manyfolks should add this scenario (at least in text). 2) The draft already allows the first provisional response with SDP to be either 180 or 183, but does not specify UAC behavior with respect to local ringtone. I don't think any change is needed here, as long as other changes are made to make it clear that 3261 text for 180 still applies (The UAC MAY generate local ringtone.). 3) Whenever a UAC receives a 183, it SHOULD stop generation of local ringtone if in progress (due to previous receipt of a 180), and be prepared to receive early media if available. Manyfolks should add this requirement and a companion scenario showing a 180 with or without SDP followed by a 183. 4) Section 12.1 includes the following text to describe what the UAC should do when receiving a 180 after having received a 183 and completed negotiation of any mandatory preconditions: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream." The second sentence should be stricken so that the UAC MAY generate local ringtone in this case. This sentence appears to be in direct contradiction to your recent decision regarding early media. 5) The text in section 12.1 continues as follows: "However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)." This text should be removed with prejudice. 6) To allow for in-band progress tones within early media, manyfolks needs to explicitly describe what to do when the UAS begins alerting the callee. It currently shows in all examples that the UAS returns a 180, but this only applies if the UAS is not generating in-band progress tones and wants the UAC to generate local ringback. Manyfolks needs a scenario to show that if there is in-band progress information in early media, the UAS should either not report alerting to the UAC or should report alerting with a 183 instead of 180. I would again appreciate your comments. Thanks and regards, Richard Ejzak -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, August 21, 2002 11:41 PM To: Ejzak, Richard P (Richard) Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: Re: [Sip] Local vs Remote ringback on 180 Hi Richard, > Christer, > Thank you for your rapid response. I had in fact looked at some of the messages from the other threat you mentioned in the sipping archive, but did not understand the final conclusion until I read your email. With all the discussion about not having a general early media solution, I took away a different impression of Jon's final solution. [CHH] There still ARE issues (eg media clipping) related to early media, which will be described as part of a general solution. > I only have a couple of questions for you: > > You said "[CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv"." This was in response to a scenario described in manyfolks where a 183 exchange resulting in sendrecv media is followed by a 180. I am confused by your comment, since elsewhere you indicate that in this scenario the UAC would generate local ringtone. [CHH] Whoops, I guess I wrote something wrong. The 180 WOULD trigger local ringback, or course :) > Did you mean to say that the 180 WOULD TRIGGER local ringtone? [CHH] Yes. > Or am I still hopelessly confused? [CHH] Hopefully not :) > And did you mean to imply that there is no change needed to the text I quoted from manyfolks? Or that this text needs to be changed as I suggested? I agree that the other text you reference from manyfolks also seems inconsistent with this recent decision. [CHH] The change/add I talked about was that the UAS would, in case there may be early media send 183 (instead of 180) when the called party has been alerted. Your comment on manyfolks was on the FIRST 183 sent, right? Regards, Christer Holmberg Ericsson Finland > > > Regards, > > Richard Ejzak > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, August 21, 2002 3:22 PM > To: Ejzak, Richard P (Richard) > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: Re: [Sip] Local vs Remote ringback on 180 > > Hi Richard, > > >I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date. (That explains the unusual >format of the attached copy of your email on July 3 from the sip archive.) > > > >I am very confused by this discussion. Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media? >According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold). And a >UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold". (Essentially >the same semantics are described in the manyfolks draft.) > > [CHH] First, the conclusion you have copied into this mail was sent BEFORE the latest discussion, where a slightly different solution was found. One difference now is that the generating of local ringback is NOT coupled to the media state - 180 now indicates that no early media is sent, so the UAC may generate local ringback no matter the media at the same time. 183 indicates that early media MAY be sent, but the UAC is recommended not to generate local ringback even if early media is sent or not. > > > I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft. The text in question is: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream. However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)." Note that this is the only text I could find anywhere that couples the meaning of 180 with the state of the UAS media. > > [CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv". > > However, the latest agreement DOES have some impacts on the manyfolks draft. The draft currently specifies that 180 is sent when the caller has been alerted (when the resource reservation has been done), but if the UAS wants to send early media 183 shall be sent instead of 180 (the sending of the FIRST 183, when the INVITE has been received, remains unchanged). > > Jon, could you please comment this manyfolks issue? > > > Here is some other relevant text from various documents. First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup draft: "Accordingly, we have amended this text in 7.2.6 and 8.2.3 to reintroduce the 183 response code as the code that should be sent when locally-generated ringtone is undesirable or inappropriate." In describing the 180 ringing response, RFC 3261 says: "The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback." But manyfolks clearly says: "A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; ..." These mandatory preconditions can only be met via successful SDP negotiation. Just for the record, I completely agree with these three quotes. > > [CHH] Again, the first provisional response sent in manyfolks is 183, which means the UAS MAY send early media, and which means the UAC should NOT generate local ringback. Of course, if the resource reservation is not done when the first 183 is sent, no early media will be sent, and no local ringback will be generated - so the caller will NOT be "alerted". Or, did I missunderstand your question? > > > Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer. Some of us have been down this road before and there is no possibility of compromise here. Any procedure requiring the use of UPDATE immediately before (or possiblity during) 200 (INVITE) to take the UAS off hold is unlikely to be reliably acceptable to the end user (IMHO). > > [CHH] The agreement means that is IS possible to set up a "sendrecv" media state using a single offer/answer transaction, even if no early media is sent, which means it's not mandatory to first set the media state to "inactive", and then to "sendrecv" when the called party answers the phone. Of course, if either party (for whatever reason) wants the media state to be "inactive" until the call has been answered it can still be done, but the major change is that it's not mandatory anymore - again, since the media state does NOT affect the decission if, or if not, to generate local ringback. > > > Allow me to propose an alternative approach. Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media. If the UAC gets a 180, it MAY initiate local ringtone. If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive). If the UAC gets a 183, it stops any locally-generated ringtone. > > [CHH] That's IS what we just have agreed upon a few days ago :) > > > If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc. Just because the UAS is not on hold does not mean that it's sending any media. > > [CHH] Exactly. > > > Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone. A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone. > > [CHH] Yes. > > > Any piggy-backing of SDP would just follow existing rules. In more complex call progress scenarios, you could freely switch between these states. And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE). Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE. > > This approach eliminates coupling between the semantics of 180 and the state of the media, eliminates the need for final UPDATE before 200 (INVITE) in a common manyfolks scenario, is consistent with current text in all RFCs and most drafts (except the one quote and some related text from manyfolks), and easily supports complex call progress scenarios involving UAS endpoints with different in-band call progress media capabilities. > > The only other consideration I can think of is that this proposal seems to make it impossible to signal an ISUP alerting indication from a CPG within SIP once in-band call progress has been established (in either direction). [E.g., it precludes 180 after 183 when you don't want local ringtone but want in-band information instead. So how do you signal ISUP alerting after in-band call progress is established?] I propose that for this case (which I think is only needed for ISUP bridging), the ISUP alerting indication be optionally passed in a MIME attachment to a 183 response rather than a 180 response, to make it clear that the UAC should not generate local ringtone. [This minor change should go in the sip-isup draft.] > > Another way of looking at my proposal is that there would be no explicit SIP indication for "the UAS is being alerted; do not generate local ringtone". A SIP UAC would do nothing if it got such an indication anyway. If ISUP needs it in a bridging scenario, the ISUP MIME attachment to 183 satisfies that need. > > I would greatly appreciate any comments on my proposal. > > [CHH] The "indicator" you mention was one of the options in the latest discussion on this. I think you should read THAT thread, because - again - the "conclusion" of mine that you attached to your mail was from a previous discussion :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > Richard Ejzak > > Lucent Technologies > > > > ------------------------------------------------------------------------------------------------------ > > email from Christer Holmberg dated July 3, 2002: > > > > Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has complete! d ! > th! > > e first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland > > > > : end of email from Christer Holmberg dated July 3, 2002 > > ------------------------------------------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 11:42:06 2002 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 LAA29693 for ; Thu, 22 Aug 2002 11:42:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MFh5u32196 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 11:43: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 g7MFfEo32006; Thu, 22 Aug 2002 11:41: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 g7MFdYo31860 for ; Thu, 22 Aug 2002 11:39:34 -0400 Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29311 for ; Thu, 22 Aug 2002 11:38:04 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g7MFd5327816; Thu, 22 Aug 2002 10:39:05 -0500 From: "Dean Willis" To: , Subject: RE: [Sip] inbound & outbound Date: Thu, 22 Aug 2002 10:38:48 -0500 Message-ID: <000d01c249f2$023caf80$a6036e3f@TXDWILLIS2> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200208220825.EAA18294@ietf.org> 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 These terms are relative to what one accepts as one's point of view in the system. Pretend you are a SIP User Agent, perhaps a very simple UA that doesn't even do DNS lookups. A call coming to you is "inbound". It may hit your home proxy first, and receive treatment such as being proxied to you based on your registered contact. This is an "inbound service", and your home proxy is acting as an "inbound proxy". Now you want to make a call. Since you're making the call, it is going "out", or can be called "outbound". You send this call to a proxy, which looks up the request URI in DNS and sends the call on towards its destination. This proxy is providing the "outbound service" of DNS resolution, and is acting as an "outbound proxy" for this call. On any call there may be any number of inbound and outbound proxies and services. Some proxies may even provide both sorts for a single call. Assume the simple network UA1----P1----P2----UA2 UA1 places a call to UA2. From UA1's perspective, P1 and P2 are outbound proxies. From UA2's perspective, they are both inbound proxies. -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of feng zhang > Sent: Thursday, August 22, 2002 12:00 AM > To: sip@ietf.org > Subject: [Sip] inbound & outbound > > > Hi All, > > Can you give me the detailed difference between: > > 1) "inbound proxy" and "outbound proxy" > > 2) "inbound services" and "outbound services" > > Thanks a lot to give me an answer! > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 22 13:08:44 2002 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 NAA02902 for ; Thu, 22 Aug 2002 13:08:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MH9fd04481 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 13:09: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 g7MH94o04445; Thu, 22 Aug 2002 13:09: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 g7MH6Xo04354 for ; Thu, 22 Aug 2002 13:06:33 -0400 Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02809 for ; Thu, 22 Aug 2002 13:05:05 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Aug 2002 12:05:58 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE92@jupiter> From: David Oliver To: "'Ejzak, Richard P (Richard)'" , "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 22 Aug 2002 12:05:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: , Richard, Comments inline... Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: mailto:doliver@securelogix.com Tel: +1.210.402.9669 Fax: +1.210.402.6996 > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com] > Sent: Thursday, August 22, 2002 9:55 AM > To: 'Christer Holmberg' > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: RE: [Sip] Local vs Remote ringback on 180 > > Christer, > Regarding manyfolks (07), I actually have several > issues/comments; most of them in section 12.1 on page 18, > referencing figure 2. I feel compelled to enumerate them > since my original comment was NOT with reference to the first 183. > <...> > > 2) The draft already allows the first provisional response > with SDP to be either 180 or 183, but does not specify UAC > behavior with respect to local ringtone. I don't think any > change is needed here, as long as other changes are made to > make it clear that 3261 text for 180 still applies (The UAC > MAY generate local ringtone.). My understanding (from 3261 and sipping) is that the UAC MAY generate local ringtone, and SHOULD do so if the UAC has the appearance/functionality of a traditional phone: a screen icon may merely blink, for example. This implies that a 180 response CANNOT rely on early media being delivered. > 3) Whenever a UAC receives a 183, it SHOULD stop generation > of local ringtone if in progress (due to previous receipt of > a 180), and be prepared to receive early media if available. > Manyfolks should add this requirement and a companion > scenario showing a 180 with or without SDP followed by a 183. I suggest that 183 SHOULD stop generation of local ringtone only when accompanied by appropriate (e.g. SDP audio) early media. 183 Session Progress is a "catch all", which may be used to convey more details about call progress: the message body could reasonably be used as a form of reverse caller id ("callee id"), such as a message saying "Ringing John Smith's phone in the ABC department of XYZ Corporation". While this could be useful to a multi-media caller, it would be undesirable for it to squelch ringback for a "black phone" user. > 4) Section 12.1 includes the following text to describe what > the UAC should do when receiving a 180 after having received > a 183 and completed negotiation of any mandatory > preconditions: "Note that now the media stream has been > already established, and A has received a 180 (Ringing) > response. Since the direction of the stream is "sendrecv", A > will not generate local ringback, since it assumes that it > will receive early media over this stream." The second > sentence should be stricken so that the UAC MAY generate > local ringtone in this case. This sentence appears to be in > direct contradiction to your recent decision regarding early media. > > 5) The text in section 12.1 continues as follows: "However, > if B wants A to generate local ringback, it can put the media > stream on hold in SDP4. In this case, B would put the media > stream off hold by sending an offer in an UPDATE request > which would be sent at the same time as the 200 (OK) for the > INVITE (10)." This text should be removed with prejudice. > > 6) To allow for in-band progress tones within early media, > manyfolks needs to explicitly describe what to do when the > UAS begins alerting the callee. It currently shows in all > examples that the UAS returns a 180, but this only applies if > the UAS is not generating in-band progress tones and wants > the UAC to generate local ringback. Manyfolks needs a > scenario to show that if there is in-band progress > information in early media, the UAS should either not report > alerting to the UAC or should report alerting with a 183 > instead of 180. This is the area where I think the problem is. 3261 indicates that 180 indicates the caller is being alerted. 183 indicates unclassified (versus Ringing, Being Forwarded, and Queued) call progress, allowing new classifications to be added (e.g. "waiting for connection availability"), which would be broken by restricting 183 to the specific meaning of Ringing-Without-Local-Ringback (RWLR). 3261/21.1.5 indicates that 183 can be qualified by the Reason-Phrase (which may be language sensitive), header fields (which are IANA managed) or the message body. I suggest the easiest of these to adopt for RWLR would be: 183 180 Ringing with early media where only the 180 is significant, the text being adaptable to the requested language. > I would again appreciate your comments. > > Thanks and regards, > Richard Ejzak <...> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 16:14:37 2002 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 QAA09137 for ; Thu, 22 Aug 2002 16:14:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MKFbZ16024 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 16:15: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 g7MKEYo15991; Thu, 22 Aug 2002 16:14: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 g7MKCjo15880 for ; Thu, 22 Aug 2002 16:12:45 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09030 for ; Thu, 22 Aug 2002 16:11:14 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7MKC9310977 for ; Thu, 22 Aug 2002 16:12:09 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 15:12:08 -0500 Message-ID: <4440C8087B6E284287E9B1AE089BA08C0DBADD@il0015exch002u.ih.lucent.com> From: "Ejzak, Richard P (Richard)" To: "'David Oliver'" , "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 22 Aug 2002 15:12:03 -0500 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: , David, You said: "I suggest that 183 SHOULD stop generation of local ringtone only when accompanied by appropriate (e.g. SDP audio) early media. 183 Session Progress is a "catch all", which may be used to convey more details about call progress: the message body could reasonably be used as a form of reverse caller id ("callee id"), such as a message saying "Ringing John Smith's phone in the ABC department of XYZ Corporation". While this could be useful to a multi-media caller, it would be undesirable for it to squelch ringback for a "black phone" user." May I respectfully suggest that your interpretation will make it difficult to handle a scenario involving redirection from a device not supporting in-band call progress to one that does? Let's assume a call from user A starts by negotiating preconditions with party B and by generating local ringtone in response to 180 with SDP. If this call is then redirected to party C, and party C has in-band call progress information, what mechanism do I use to signal this change according to your interpretation? With your interpretation, I can never switch from generation of local ringtone to in-band call progress information after SDP negotiation begins. There is an easy fix for this problem: If there is a need to send a Reason-Phrase to indicate the handling of a call, then use 183 to carry it if you do not want the UAC to generate local ringtone (probably because there is in-band call progress information), and use 180 to carry it if you wish the UAC to continue to generate local ringtone. This allows you to signal unclassified call progress information back to the UAC in all cases. Every 180 in sequence after the first can be interpreted as just a generic session progress response. You go on to say: "This is the area where I think the problem is. 3261 indicates that 180 indicates the caller is being alerted. 183 indicates unclassified (versus Ringing, Being Forwarded, and Queued) call progress, allowing new classifications to be added (e.g. "waiting for connection availability"), which would be broken by restricting 183 to the specific meaning of Ringing-Without-Local-Ringback (RWLR)." I further stated (and the current early media agreement for the sip-isup draft apparently says) that a UAS should use 183 to signal alerting while progress information is coming in-band. You correctly point out that this makes it impossible for the UAS to report unclassified call progress information while there is in-band call progress information, without providing an alerting indication. "3261/21.1.5 indicates that 183 can be qualified by the Reason-Phrase (which may be language sensitive), header fields (which are IANA managed) or the message body. I suggest the easiest of these to adopt for RWLR would be: 183 180 Ringing with early media where only the 180 is significant, the text being adaptable to the requested language." I actually like this solution very much. A SIP entity receiving an alerting indication while being prohibited from generating local ringtone will behave exactly like a SIP entity receiving a 183 - it will do some vendor-specific thing (perhaps nothing) with the contents of the Reason-Phrase. So if you use 183 to send this Reason-Phrase, there is no loss in functionality for a SIP UAC/UAS. For an MGC providing interworking with the PSTN, it adds an additional processing burden local to the MGC: interwork a PSTN alerting indication while there is in-band progress information with a 183 response carrying a Reason-Phrase beginning with "180". I like it! I think this is much better than the "solution 1". The first change should probably be reflected in both manyfolks and sip-isup. Your proposed change only needs to be in the sip-isup draft. The ISUP event code to SIP response map in the sip-isup draft would allow either 180 or 183 to be used with event codes 1, 2, 3 or -. Regards, Richard Ejzak -----Original Message----- From: David Oliver [mailto:Oliverdc@securelogix.com] Sent: Thursday, August 22, 2002 12:06 PM To: 'Ejzak, Richard P (Richard)'; 'Christer Holmberg' Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: RE: [Sip] Local vs Remote ringback on 180 Richard, Comments inline... Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: mailto:doliver@securelogix.com Tel: +1.210.402.9669 Fax: +1.210.402.6996 > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com] > Sent: Thursday, August 22, 2002 9:55 AM > To: 'Christer Holmberg' > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: RE: [Sip] Local vs Remote ringback on 180 > > Christer, > Regarding manyfolks (07), I actually have several > issues/comments; most of them in section 12.1 on page 18, > referencing figure 2. I feel compelled to enumerate them > since my original comment was NOT with reference to the first 183. > <...> > > 2) The draft already allows the first provisional response > with SDP to be either 180 or 183, but does not specify UAC > behavior with respect to local ringtone. I don't think any > change is needed here, as long as other changes are made to > make it clear that 3261 text for 180 still applies (The UAC > MAY generate local ringtone.). My understanding (from 3261 and sipping) is that the UAC MAY generate local ringtone, and SHOULD do so if the UAC has the appearance/functionality of a traditional phone: a screen icon may merely blink, for example. This implies that a 180 response CANNOT rely on early media being delivered. > 3) Whenever a UAC receives a 183, it SHOULD stop generation > of local ringtone if in progress (due to previous receipt of > a 180), and be prepared to receive early media if available. > Manyfolks should add this requirement and a companion > scenario showing a 180 with or without SDP followed by a 183. I suggest that 183 SHOULD stop generation of local ringtone only when accompanied by appropriate (e.g. SDP audio) early media. 183 Session Progress is a "catch all", which may be used to convey more details about call progress: the message body could reasonably be used as a form of reverse caller id ("callee id"), such as a message saying "Ringing John Smith's phone in the ABC department of XYZ Corporation". While this could be useful to a multi-media caller, it would be undesirable for it to squelch ringback for a "black phone" user. > 4) Section 12.1 includes the following text to describe what > the UAC should do when receiving a 180 after having received > a 183 and completed negotiation of any mandatory > preconditions: "Note that now the media stream has been > already established, and A has received a 180 (Ringing) > response. Since the direction of the stream is "sendrecv", A > will not generate local ringback, since it assumes that it > will receive early media over this stream." The second > sentence should be stricken so that the UAC MAY generate > local ringtone in this case. This sentence appears to be in > direct contradiction to your recent decision regarding early media. > > 5) The text in section 12.1 continues as follows: "However, > if B wants A to generate local ringback, it can put the media > stream on hold in SDP4. In this case, B would put the media > stream off hold by sending an offer in an UPDATE request > which would be sent at the same time as the 200 (OK) for the > INVITE (10)." This text should be removed with prejudice. > > 6) To allow for in-band progress tones within early media, > manyfolks needs to explicitly describe what to do when the > UAS begins alerting the callee. It currently shows in all > examples that the UAS returns a 180, but this only applies if > the UAS is not generating in-band progress tones and wants > the UAC to generate local ringback. Manyfolks needs a > scenario to show that if there is in-band progress > information in early media, the UAS should either not report > alerting to the UAC or should report alerting with a 183 > instead of 180. This is the area where I think the problem is. 3261 indicates that 180 indicates the caller is being alerted. 183 indicates unclassified (versus Ringing, Being Forwarded, and Queued) call progress, allowing new classifications to be added (e.g. "waiting for connection availability"), which would be broken by restricting 183 to the specific meaning of Ringing-Without-Local-Ringback (RWLR). 3261/21.1.5 indicates that 183 can be qualified by the Reason-Phrase (which may be language sensitive), header fields (which are IANA managed) or the message body. I suggest the easiest of these to adopt for RWLR would be: 183 180 Ringing with early media where only the 180 is significant, the text being adaptable to the requested language. > I would again appreciate your comments. > > Thanks and regards, > Richard Ejzak <...> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 16:21:10 2002 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 QAA09354 for ; Thu, 22 Aug 2002 16:21:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MKMA316279 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 16:22:10 -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 g7MKLLo16225; Thu, 22 Aug 2002 16:21: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 g7MKK3o16182 for ; Thu, 22 Aug 2002 16:20:03 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09290 for ; Thu, 22 Aug 2002 16:18:32 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7MKJR314006 for ; Thu, 22 Aug 2002 16:19:27 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 15:19:26 -0500 Message-ID: <4440C8087B6E284287E9B1AE089BA08C0DBADE@il0015exch002u.ih.lucent.com> From: "Ejzak, Richard P (Richard)" To: "'Elwell, John'" , "'christer.holmberg@lmf.ericsson.se'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 22 Aug 2002 15:19:21 -0500 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: , John, As I started writing a response to your mail, another response came in from David Oliver that contains what seems to be a reasonable solution to your problem. Please allow me to refer you to David's email and my response. Regards, Richard Ejzak -----Original Message----- From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk] Sent: Thursday, August 22, 2002 9:33 AM To: 'Ejzak, Richard P (Richard)'; 'christer.holmberg@lmf.ericsson.se' Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: RE: [Sip] Local vs Remote ringback on 180 Richard, You wrote: > The only other consideration I can think of is that this > proposal seems to make it impossible to signal an ISUP > alerting indication from a CPG within SIP once in-band call > progress has been established (in either direction). [E.g., > it precludes 180 after 183 when you don't want local ringtone > but want in-band information instead. So how do you signal > ISUP alerting after in-band call progress is established?] I > propose that for this case (which I think is only needed for > ISUP bridging), the ISUP alerting indication be optionally > passed in a MIME attachment to a 183 response rather than a > 180 response, to make it clear that the UAC should not > generate local ringtone. [This minor change should go in the > sip-isup draft.] Similarly, it does not allow us to signal a QSIG ALERTING message accompanied by in-band tone or announcement. If it is signalled as 180, local ring-back tone might be applied and the remote tone or announcement lost. If it is signalled as 183, a QSIG UAC will map to PROGRESS rather than ALERTING, and this could have implications in the originating QSIG network or at the caller's equipment. Although we could solve this QSIG-SIP-QSIG scenario by tunnelling QSIG in MIME, this solution will not work for QSIG-SIP-ISUP and ISUP-SIP-QSIG scenarios. I made this point a few days ago on the SIPPING thread and have not had an answer. John -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 16:59:43 2002 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 QAA10731 for ; Thu, 22 Aug 2002 16:59:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7ML0id19059 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 17:00: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 g7MKx7o18154; Thu, 22 Aug 2002 16:59: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 g7MKvwo18100 for ; Thu, 22 Aug 2002 16:57:58 -0400 Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10495 for ; Thu, 22 Aug 2002 16:56:27 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Aug 2002 15:57:22 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE95@jupiter> From: David Oliver To: "'Ejzak, Richard P (Richard)'" , David Oliver , "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs. Remote ringback on 180 Date: Thu, 22 Aug 2002 15:57:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: , Richard, (More) comments inline... David C. Oliver Principal Engineer SecureLogix Corp Email: mailto:doliver@securelogix.com Tel: +1.210.402.9669 Fax: +1.210.402.6996 > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com] > Sent: Thursday, August 22, 2002 3:12 PM > To: 'David Oliver'; 'Christer Holmberg' > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: RE: [Sip] Local vs. Remote ringback on 180 > > > David, > You said: "I suggest that 183 SHOULD stop generation of local > ringtone only when accompanied by appropriate (e.g. SDP audio) > early media. 183 Session Progress is a "catch all", which may > be used to convey more details about call progress: the > message body could reasonably be used as a form of reverse > caller id ("callee id"), such as a message saying "Ringing > John Smith's phone in the ABC department of XYZ Corporation". > While this could be useful to a multi-media caller, it would > be undesirable for it to squelch ringback for a "black phone" > user." > > May I respectfully suggest that your interpretation will make > it difficult to handle a scenario involving redirection from > a device not supporting in-band call progress to one that > does? Let's assume a call from user A starts by negotiating > preconditions with party B and by generating local ringtone > in response to 180 with SDP. If this call is then redirected > to party C, and party C has in-band call progress > information, what mechanism do I use to signal this change > according to your interpretation? With your interpretation, > I can never switch from generation of local ringtone to > in-band call progress information after SDP negotiation begins. A would suppress local ringback when C sent a 183 with SDP in its body indicating early media. I agree this is ugly as the coupling is indirect. > There is an easy fix for this problem: If there is a need to > send a Reason-Phrase to indicate the handling of a call, then > use 183 to carry it if you do not want the UAC to generate > local ringtone (probably because there is in-band call > progress information), and use 180 to carry it if you wish > the UAC to continue to generate local ringtone. This allows > you to signal unclassified call progress information back to > the UAC in all cases. Every 180 in sequence after the first > can be interpreted as just a generic session progress response. This works: 180 now means "Callee is (still) being alerted; UAC MAY (continue to) play local ringtone" - merely clarifying the semantics. > You go on to say: "This is the area where I think the > problem is. 3261 indicates that 180 indicates the caller > is being alerted. 183 indicates unclassified (versus > Ringing, Being Forwarded, and Queued) call progress, > allowing new classifications to be added (e.g. "waiting > for connection availability"), which would be broken by > restricting 183 to the specific meaning of > Ringing-Without-Local-Ringback (RWLR)." > > I further stated (and the current early media agreement for > the sip-isup draft apparently says) that a UAS should use 183 > to signal alerting while progress information is coming > in-band. You correctly point out that this makes it > impossible for the UAS to report unclassified call progress > information while there is in-band call progress information, > without providing an alerting indication. > > "3261/21.1.5 indicates that 183 can be qualified by the > Reason-Phrase (which may be language sensitive), header > fields (which are IANA managed) or the message body. I > suggest the easiest of these to adopt for RWLR would be: > > 183 180 Ringing with early media > > where only the 180 is significant, the text being adaptable > to the requested language." > > I actually like this solution very much. A SIP entity > receiving an alerting indication while being prohibited from > generating local ringtone will behave exactly like a SIP > entity receiving a 183 - it will do some vendor-specific > thing (perhaps nothing) with the contents of the > Reason-Phrase. So if you use 183 to send this Reason-Phrase, > there is no loss in functionality for a SIP UAC/UAS. For an > MGC providing interworking with the PSTN, it adds an > additional processing burden local to the MGC: interwork a > PSTN alerting indication while there is in-band progress > information with a 183 response carrying a Reason-Phrase > beginning with "180". I like it! I think this is much > better than the "solution 1". I must concur :-) In other words, the alerting/local ringback combinations are: 180 (still) alerting; MAY (continue to) play local ringback 183 180 (still) alerting; SHOULD NOT (continue to) play local ringback 183 alerting unchanged; local ringback unchanged > The first change should probably be reflected in both > manyfolks and sip-isup. Your proposed change only needs to > be in the sip-isup draft. The ISUP event code to SIP > response map in the sip-isup draft would allow either 180 or > 183 to be used with event codes 1, 2, 3 or -. > > Regards, > Richard Ejzak _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 17:57:34 2002 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 RAA11851 for ; Thu, 22 Aug 2002 17:57:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MLwZF21058 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 17:58: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 g7MLvXo21040; Thu, 22 Aug 2002 17:57: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 g7MLuFo21006 for ; Thu, 22 Aug 2002 17:56:15 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11818 for ; Thu, 22 Aug 2002 17:54:43 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7MLu8e12657 for ; Thu, 22 Aug 2002 17:56:08 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 16:56:07 -0500 Message-ID: <4440C8087B6E284287E9B1AE089BA08C0DBAE0@il0015exch002u.ih.lucent.com> From: "Ejzak, Richard P (Richard)" To: "'David Oliver'" , "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs. Remote ringback on 180 Date: Thu, 22 Aug 2002 16:56:04 -0500 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: , David, I would suggest the following combinations: 180 provide alerting indication when interworking; MAY (continue to) play local ringback 183 180 provide alerting indication when interworking; SHOULD NOT (continue to) play local ringback 183 provide progress indication when interworking; SHOULD NOT (continue to) play local ringback All of these combinations may include a Reason-Phrase for display of additional information for SIP UAs that can process them. I don't think the "(still) alerting" indication is very meaningful. The only thing a SIP UA cares about is whether or not to generate local ringtone - either message can otherwise carry a message for display. So the first line just describes what to do at a MGC when interworking the signaling; the second line describes what to do at the media level. The only significant change from your list is the last combination. I suggest the use of 180 for miscellaneous progress information while playing local ringtone. Your combinations can be made to work, but make it impossible to turn off local ringtone without sending an alerting indication. Regards, Richard Ejzak -----Original Message----- From: David Oliver [mailto:Oliverdc@securelogix.com] Sent: Thursday, August 22, 2002 3:57 PM To: 'Ejzak, Richard P (Richard)'; David Oliver; 'Christer Holmberg' Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: RE: [Sip] Local vs. Remote ringback on 180 Richard, (More) comments inline... David C. Oliver Principal Engineer SecureLogix Corp Email: mailto:doliver@securelogix.com Tel: +1.210.402.9669 Fax: +1.210.402.6996 > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com] > Sent: Thursday, August 22, 2002 3:12 PM > To: 'David Oliver'; 'Christer Holmberg' > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: RE: [Sip] Local vs. Remote ringback on 180 > > > David, > You said: "I suggest that 183 SHOULD stop generation of local > ringtone only when accompanied by appropriate (e.g. SDP audio) > early media. 183 Session Progress is a "catch all", which may > be used to convey more details about call progress: the > message body could reasonably be used as a form of reverse > caller id ("callee id"), such as a message saying "Ringing > John Smith's phone in the ABC department of XYZ Corporation". > While this could be useful to a multi-media caller, it would > be undesirable for it to squelch ringback for a "black phone" > user." > > May I respectfully suggest that your interpretation will make > it difficult to handle a scenario involving redirection from > a device not supporting in-band call progress to one that > does? Let's assume a call from user A starts by negotiating > preconditions with party B and by generating local ringtone > in response to 180 with SDP. If this call is then redirected > to party C, and party C has in-band call progress > information, what mechanism do I use to signal this change > according to your interpretation? With your interpretation, > I can never switch from generation of local ringtone to > in-band call progress information after SDP negotiation begins. A would suppress local ringback when C sent a 183 with SDP in its body indicating early media. I agree this is ugly as the coupling is indirect. > There is an easy fix for this problem: If there is a need to > send a Reason-Phrase to indicate the handling of a call, then > use 183 to carry it if you do not want the UAC to generate > local ringtone (probably because there is in-band call > progress information), and use 180 to carry it if you wish > the UAC to continue to generate local ringtone. This allows > you to signal unclassified call progress information back to > the UAC in all cases. Every 180 in sequence after the first > can be interpreted as just a generic session progress response. This works: 180 now means "Callee is (still) being alerted; UAC MAY (continue to) play local ringtone" - merely clarifying the semantics. > You go on to say: "This is the area where I think the > problem is. 3261 indicates that 180 indicates the caller > is being alerted. 183 indicates unclassified (versus > Ringing, Being Forwarded, and Queued) call progress, > allowing new classifications to be added (e.g. "waiting > for connection availability"), which would be broken by > restricting 183 to the specific meaning of > Ringing-Without-Local-Ringback (RWLR)." > > I further stated (and the current early media agreement for > the sip-isup draft apparently says) that a UAS should use 183 > to signal alerting while progress information is coming > in-band. You correctly point out that this makes it > impossible for the UAS to report unclassified call progress > information while there is in-band call progress information, > without providing an alerting indication. > > "3261/21.1.5 indicates that 183 can be qualified by the > Reason-Phrase (which may be language sensitive), header > fields (which are IANA managed) or the message body. I > suggest the easiest of these to adopt for RWLR would be: > > 183 180 Ringing with early media > > where only the 180 is significant, the text being adaptable > to the requested language." > > I actually like this solution very much. A SIP entity > receiving an alerting indication while being prohibited from > generating local ringtone will behave exactly like a SIP > entity receiving a 183 - it will do some vendor-specific > thing (perhaps nothing) with the contents of the > Reason-Phrase. So if you use 183 to send this Reason-Phrase, > there is no loss in functionality for a SIP UAC/UAS. For an > MGC providing interworking with the PSTN, it adds an > additional processing burden local to the MGC: interwork a > PSTN alerting indication while there is in-band progress > information with a 183 response carrying a Reason-Phrase > beginning with "180". I like it! I think this is much > better than the "solution 1". I must concur :-) In other words, the alerting/local ringback combinations are: 180 (still) alerting; MAY (continue to) play local ringback 183 180 (still) alerting; SHOULD NOT (continue to) play local ringback 183 alerting unchanged; local ringback unchanged > The first change should probably be reflected in both > manyfolks and sip-isup. Your proposed change only needs to > be in the sip-isup draft. The ISUP event code to SIP > response map in the sip-isup draft would allow either 180 or > 183 to be used with event codes 1, 2, 3 or -. > > Regards, > Richard Ejzak _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 22 18:08:40 2002 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 SAA12038 for ; Thu, 22 Aug 2002 18:08:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MM9gh21860 for sip-archive@odin.ietf.org; Thu, 22 Aug 2002 18:09: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 g7MM9Jo21847; Thu, 22 Aug 2002 18:09: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 g7MM8fo21810 for ; Thu, 22 Aug 2002 18:08:41 -0400 Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12018 for ; Thu, 22 Aug 2002 18:07:09 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Aug 2002 17:08:04 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE96@jupiter> From: David Oliver To: "'Ejzak, Richard P (Richard)'" , David Oliver , "'Christer Holmberg'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Subject: RE: [Sip] Local vs. Remote ringback on 180 Date: Thu, 22 Aug 2002 17:07:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: , Richard, They work for me. Regards, David O. > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com] > Sent: Thursday, August 22, 2002 4:56 PM > To: 'David Oliver'; 'Christer Holmberg' > Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' > Subject: RE: [Sip] Local vs. Remote ringback on 180 > > > David, > I would suggest the following combinations: > > 180 provide alerting indication when interworking; > MAY (continue to) play local ringback > > 183 180 provide alerting indication when interworking; > SHOULD NOT (continue to) play local ringback > > 183 provide progress indication when interworking; > SHOULD NOT (continue to) play local ringback > > All of these combinations may include a Reason-Phrase for > display of additional information for SIP UAs that can process them. > > I don't think the "(still) alerting" indication is very > meaningful. The only thing a SIP UA cares about is whether > or not to generate local ringtone - either message can > otherwise carry a message for display. So the first line > just describes what to do at a MGC when interworking the > signaling; the second line describes what to do at the media level. > > The only significant change from your list is the last > combination. I suggest the use of 180 for miscellaneous > progress information while playing local ringtone. Your > combinations can be made to work, but make it impossible to > turn off local ringtone without sending an alerting indication. > > Regards, > Richard Ejzak <...> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 06:05:29 2002 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 GAA02584 for ; Fri, 23 Aug 2002 06:05:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NA6PB29255 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 06:06: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 g7NA64o29244; Fri, 23 Aug 2002 06:06: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 g7NA5po29213 for ; Fri, 23 Aug 2002 06:05:51 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02568 for ; Fri, 23 Aug 2002 06:04:24 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7NA5FYH007944; Fri, 23 Aug 2002 06:05:15 -0400 (EDT) Message-ID: <3D6608DB.7040807@dynamicsoft.com> Date: Fri, 23 Aug 2002 06:05:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Medhavi Bhatia CC: hisham.khartabil@nokia.com, christer.holmberg@lmf.ericsson.se, sip@ietf.org Subject: Re: [Sip] Mandatory header changed in response References: <006201c2485a$c6af50f0$1fe4b4cc@laptopeng3> 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 spec is clear on how responses are constructed, and that includes copying the CSeq and To as is, with the possible addition of a To tag. These are MUST strength requirements. Therefore, a UAC receiving a response that has a modified To, CSeq, or something else, is talking to a mis-implemented UAS. As I have stated many times, the spec does not attempt to prescribe behavior for every strange (and generally, uncorrectable) error situation, this one included. It is an implementation issue how you deal with it if it occurs, but there is no expectation of proper operation in this scenario. -Jonathan R. Medhavi Bhatia wrote: > The spec mentions that the UAS must match the headers in the response. > That > has to be done at the transaction layer of the UAS, before the response > is > accepted and delivered to the core. > > I guess the transaction layer description should be updated to reflect > that... > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, August 20, 2002 8:40 AM > Subject: RE: [Sip] Mandatory header changed in response > > > >>The point is that its too late to discard since the transactions layer > > accepted it and moved to the next state, so no retransmissions. > >>Its not an implementation issue when To-header gets changed in a 200 > > Ok > for an REGISTER, for example. Or when CSeq gets changed in 200 OK for > INVITE. What does Server Core do? > >>/Hisham >> >> >>>-----Original Message----- >>>From: ext Christer Holmberg >> > [mailto:christer.holmberg@lmf.ericsson.se] > >>>Sent: Tuesday, August 20, 2002 1:05 PM >>>To: Khartabil Hisham (NMP/Helsinki) >>>Cc: sip@ietf.org >>>Subject: Re: [Sip] Mandatory header changed in response >>> >>> >>> >>>Hi, >>> >>>I would regard is as an implementation issue, ie you choose >>>if you don't care about the changed header values, or if you >>>discard the message etc. >>> >>>Regards, >>> >>>Christer Holmberg >>>Ericsson Finland >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>Now that matching responses to requests is done using >>> >>>branch-id. How should the behaviour be when a mandatory >>>header has been modified in the response? >>> >>>>E.g. 1 >>>> >>>>REGISTER ... >>>>To: sip:hisham.khartabil@nokia.com >>>>Contact: sip:hisham.khartabil@pc.nokia.com >>>>... >>>> >>>>200 Ok >>>>To: sip:someonelese@nokia.com >>>>Contact: sip:hisham.khartabil@pc.nokia.com >>>>... >>>> >>>>Do we accept that a binding has been created? >>>> >>>>E.g. 2 >>>> >>>>INVITE >>>>... >>>>CSeq: 1 INVITE >>>> >>>>200 ok >>>>... >>>>CSeq: 15 INVITE >>>> >>>>This affects the local sequence number. Which one to store >>> >>>and use for requests within dialogs? >>> >>>>Thanks, >>>>Hisham >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>> > sip > >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 Fri Aug 23 06:27:47 2002 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 GAA02863 for ; Fri, 23 Aug 2002 06:27:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NASi029838 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 06:28: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 g7NASLo29830; Fri, 23 Aug 2002 06:28: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 g7NARjo29809 for ; Fri, 23 Aug 2002 06:27:45 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02836 for ; Fri, 23 Aug 2002 06:26:17 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7NARdRb002972; Fri, 23 Aug 2002 12:27:39 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.173]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7NARca9006684; Fri, 23 Aug 2002 13:27:38 +0300 (EET DST) Message-ID: <3D660E1A.E3EA9909@lmf.ericsson.se> Date: Fri, 23 Aug 2002 13:27:39 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Medhavi Bhatia , hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Mandatory header changed in response References: <006201c2485a$c6af50f0$1fe4b4cc@laptopeng3> <3D6608DB.7040807@dynamicsoft.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, > The spec is clear on how responses are constructed, and that includes > copying the CSeq and To as is, with the possible addition of a To tag. > These are MUST strength requirements. Does "as is" also mean that all possible parameters must be in the same order, and does it also mean we're not allowed to add/remove "<" and ">" characters around the uri. In other words: is it required to do a byte copy of the whole header from the request into the response? Personally I think that would be a bad idea, since the "url comparision" rules do NOT require that. Regards, Christer Holmberg Ericsson Finland > > > Therefore, a UAC receiving a response that has a modified To, CSeq, or > something else, is talking to a mis-implemented UAS. As I have stated > many times, the spec does not attempt to prescribe behavior for every > strange (and generally, uncorrectable) error situation, this one > included. It is an implementation issue how you deal with it if it > occurs, but there is no expectation of proper operation in this scenario. > > -Jonathan R. > > Medhavi Bhatia wrote: > > The spec mentions that the UAS must match the headers in the response. > > That > > has to be done at the transaction layer of the UAS, before the response > > is > > accepted and delivered to the core. > > > > I guess the transaction layer description should be updated to reflect > > that... > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Tuesday, August 20, 2002 8:40 AM > > Subject: RE: [Sip] Mandatory header changed in response > > > > > > > >>The point is that its too late to discard since the transactions layer > > > > accepted it and moved to the next state, so no retransmissions. > > > >>Its not an implementation issue when To-header gets changed in a 200 > > > > Ok > > for an REGISTER, for example. Or when CSeq gets changed in 200 OK for > > INVITE. What does Server Core do? > > > >>/Hisham > >> > >> > >>>-----Original Message----- > >>>From: ext Christer Holmberg > >> > > [mailto:christer.holmberg@lmf.ericsson.se] > > > >>>Sent: Tuesday, August 20, 2002 1:05 PM > >>>To: Khartabil Hisham (NMP/Helsinki) > >>>Cc: sip@ietf.org > >>>Subject: Re: [Sip] Mandatory header changed in response > >>> > >>> > >>> > >>>Hi, > >>> > >>>I would regard is as an implementation issue, ie you choose > >>>if you don't care about the changed header values, or if you > >>>discard the message etc. > >>> > >>>Regards, > >>> > >>>Christer Holmberg > >>>Ericsson Finland > >>> > >>>hisham.khartabil@nokia.com wrote: > >>> > >>> > >>>>Now that matching responses to requests is done using > >>> > >>>branch-id. How should the behaviour be when a mandatory > >>>header has been modified in the response? > >>> > >>>>E.g. 1 > >>>> > >>>>REGISTER ... > >>>>To: sip:hisham.khartabil@nokia.com > >>>>Contact: sip:hisham.khartabil@pc.nokia.com > >>>>... > >>>> > >>>>200 Ok > >>>>To: sip:someonelese@nokia.com > >>>>Contact: sip:hisham.khartabil@pc.nokia.com > >>>>... > >>>> > >>>>Do we accept that a binding has been created? > >>>> > >>>>E.g. 2 > >>>> > >>>>INVITE > >>>>... > >>>>CSeq: 1 INVITE > >>>> > >>>>200 ok > >>>>... > >>>>CSeq: 15 INVITE > >>>> > >>>>This affects the local sequence number. Which one to store > >>> > >>>and use for requests within dialogs? > >>> > >>>>Thanks, > >>>>Hisham > >>>> > >>>>_______________________________________________ > >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>This list is for NEW development of the core SIP Protocol > >>>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>Use sipping@ietf.org for new developments on the application of > >>> > > sip > > > >>> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use sip-implementors@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. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > 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 Fri Aug 23 06:53:43 2002 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 GAA02583 for ; Fri, 23 Aug 2002 06:05:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NA6PF29254 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 06:06: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 g7NA5ro29219; Fri, 23 Aug 2002 06:05: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 g7NA35o29146 for ; Fri, 23 Aug 2002 06:03:05 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02472 for ; Fri, 23 Aug 2002 06:01:38 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7NA2AYH007941; Fri, 23 Aug 2002 06:02:16 -0400 (EDT) Message-ID: <3D660822.40301@dynamicsoft.com> Date: Fri, 23 Aug 2002 06:02:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: y01317@njupt.edu.cn CC: sip@ietf.org Subject: Re: [Sip] SIP session timer References: <200208201224.IAA11625@ietf.org> Content-Type: text/plain; charset=GB2312 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 When the client sends an initial INVITE, it uses a particular call-ID. If it receives a 422 to that INVITE, it generates a new INVITE with the same Call-ID. THis new INVITE has a Min-SE header, whose value is the largest Min-SE returned in all 422 responses to an INVITE with the same Call-ID. In this case, its the one previous 422, so that Min-SE is used. If this second INVITE should generate another 422, it tries a third time, this time with the Min-SE being the maximum of the previous two. This rule is not clear from the draft. I will clarify. -Jonathan R. feng zhang wrote: > Hi All, > > I'm reading draft-ietf-sip-session-timer-09.txt, and I meet a question > in the draft. > > in Page 9 (7.1 Generating a Session Refresh Request), it mentions: > "The value of the Min-SE header field present in a session refresh > request MUST be the largest value amongst all Min-SE header field > values returned in all 422 responses, or received in session refresh > requests, on the same dialog, if a dialog has been established. If no > dialog has been established, the Min-SE header field value is set to > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~Since the dialog has not been > established, > then what is "the same Call-ID" mentioned > below > > the largest value amongst all Min-SE header field values returned in > all 422 responses for an INVITE request with the same Call-ID. A > ~~~~~~~~~~~~~~~~~~~~~~ > comparing with other > dialog's Call-ID? > > result of this rule is that the maximum value of the Min-SE is > effectively "cleared" once the dialog is established, and from that > point on, only the values from proxies known to be on the proxy path > will end up being used." > > Thanks a lot to give an answer! > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 Fri Aug 23 06:59:29 2002 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 GAA03267 for ; Fri, 23 Aug 2002 06:59:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NB0QY31712 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 07:00: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 g7NAuGo31009; Fri, 23 Aug 2002 06:56: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 g7NAtso30985 for ; Fri, 23 Aug 2002 06:55:54 -0400 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03169 for ; Fri, 23 Aug 2002 06:54:25 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7NAs1l08569 for ; Fri, 23 Aug 2002 13:54:01 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 23 Aug 2002 13:55:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 Aug 2002 13:55:38 +0300 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 Aug 2002 13:55:13 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20511@esebe019.ntc.nokia.com> Thread-Topic: Max-Forward checking at UAS Thread-Index: AcJKk47uj1Br2WaAQ+ucOf3SbrDQ5Q== To: X-OriginalArrivalTime: 23 Aug 2002 10:55:38.0257 (UTC) FILETIME=[9D7BA810:01C24A93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7NAtso30986 Subject: [Sip] Max-Forward checking at UAS 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 RFC3261 is silent about the behaviour of UAS when a request is received with no Max-Forwards header or a Max-Forwards header with value 0. The behaviour for a proxy is well defined in section 16, but not in section 8 for a UAS behaviour. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Aug 23 07:37:25 2002 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 HAA04036 for ; Fri, 23 Aug 2002 07:37:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NBcN800601 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 07:38: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 g7NBboo00580; Fri, 23 Aug 2002 07:37: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 g7NBawo00551 for ; Fri, 23 Aug 2002 07:36:58 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04000 for ; Fri, 23 Aug 2002 07:35:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7NBasRb007127; Fri, 23 Aug 2002 13:36:54 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.173]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7NBasa9013188; Fri, 23 Aug 2002 14:36:54 +0300 (EET DST) Message-ID: <3D661E56.9B42241E@lmf.ericsson.se> Date: Fri, 23 Aug 2002 14:36:54 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Max-Forward checking at UAS References: <2038BCC78B1AD641891A0D1AE133DBB7C20511@esebe019.ntc.nokia.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, > RFC3261 is silent about the behaviour of UAS when a request is received with no Max-Forwards header or a Max-Forwards header with value 0. The behaviour for a proxy is well defined in section 16, but not in section 8 for a UAS behaviour. Since Max-Forwards is a mandatory header, if it's not in the received message I guess the UAS should treat the message the same way it would treat it if any other mandatory header (To, From, Call-Id, CSeq or Via) would be missing. If there is a Max-Forwards header, and the value is zero, at least chapter 21.4.21 explains what to do. Of course it could also be described in chapter 8.2, but chapter 8.1.1.6 DOES explain what a SERVER shall do (even if the chapter itself describes UAC behaviour). Regards, Christer Holmberg Ericsson Finland > > > Regards, > Hisham > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 07:56:49 2002 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 HAA04301 for ; Fri, 23 Aug 2002 07:56:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NBvjb00898 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 07:57: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 g7NBvHo00890; Fri, 23 Aug 2002 07:57: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 g7NBuko00869 for ; Fri, 23 Aug 2002 07:56:46 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04267 for ; Fri, 23 Aug 2002 07:55:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7NC92f01157 for ; Fri, 23 Aug 2002 15:09:02 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 Aug 2002 14:56:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 Aug 2002 14:56:42 +0300 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" Subject: RE: [Sip] Max-Forward checking at UAS Date: Fri, 23 Aug 2002 14:56:42 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20514@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Max-Forward checking at UAS Thread-Index: AcJKmWMugAbdPRCbSimhBbGm3SoOYgAAfG3A To: Cc: X-OriginalArrivalTime: 23 Aug 2002 11:56:42.0665 (UTC) FILETIME=[25A3F190:01C24A9C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7NBuko00870 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 > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, August 23, 2002 2:37 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] Max-Forward checking at UAS > > > > > Hi, > > > RFC3261 is silent about the behaviour of UAS when a request > is received with no Max-Forwards header or a Max-Forwards > header with value 0. The behaviour for a proxy is well > defined in section 16, but not in section 8 for a UAS behaviour. > > Since Max-Forwards is a mandatory header, if it's not in the > received message I guess the UAS should treat the message the > same way it would treat it if any other mandatory header (To, > From, Call-Id, CSeq or Via) would be missing. I actually disagree here for backwards compatibility. If max-forwards is missing, the UAS assumes the max-forwards test has passed and go on processing the request as normal (that's how a proxy is defined to behave). /Hisham > > If there is a Max-Forwards header, and the value is zero, at > least chapter 21.4.21 explains what to do. Of course it could > also be described in chapter 8.2, but chapter 8.1.1.6 DOES > explain what a SERVER shall do (even if the chapter itself > describes UAC behaviour). > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > Regards, > > Hisham > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 08:26:31 2002 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 IAA04734 for ; Fri, 23 Aug 2002 08:26:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NCRRg02184 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 08:27: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 g7NCIOo02034; Fri, 23 Aug 2002 08:18: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 g7NCHBo01998 for ; Fri, 23 Aug 2002 08:17:11 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04646 for ; Fri, 23 Aug 2002 08:15:44 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7NCH8Rb026751; Fri, 23 Aug 2002 14:17:08 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.173]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7NCH7a9017081; Fri, 23 Aug 2002 15:17:07 +0300 (EET DST) Message-ID: <3D6627C3.DAE2C38A@lmf.ericsson.se> Date: Fri, 23 Aug 2002 15:17:07 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Max-Forward checking at UAS References: <2038BCC78B1AD641891A0D1AE133DBB7C20514@esebe019.ntc.nokia.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, > > -----Original Message----- > > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, August 23, 2002 2:37 PM > > To: Khartabil Hisham (NMP/Helsinki) > > Cc: sip@ietf.org > > Subject: Re: [Sip] Max-Forward checking at UAS > > > > > > > > > > Hi, > > > > > RFC3261 is silent about the behaviour of UAS when a request > > is received with no Max-Forwards header or a Max-Forwards > > header with value 0. The behaviour for a proxy is well > > defined in section 16, but not in section 8 for a UAS behaviour. > > > > Since Max-Forwards is a mandatory header, if it's not in the > > received message I guess the UAS should treat the message the > > same way it would treat it if any other mandatory header (To, > > From, Call-Id, CSeq or Via) would be missing. > > I actually disagree here for backwards compatibility. If max-forwards is missing, the UAS assumes the max-forwards test has passed and go on processing the request as normal (that's how a proxy is defined to behave). The UAS could check the Via branch-id, to see if the Max-Forwards header is mandatory for that specific message or not. The UAS will have to check the branch-id it anyway, to find out if it is able to use it as transaction identifier, or if it will have to do it the "old way" (ie using CSeq, Call-ID, etc) Regards, Christer Holmberg Ericsson Finland > > > /Hisham > > > > > If there is a Max-Forwards header, and the value is zero, at > > least chapter 21.4.21 explains what to do. Of course it could > > also be described in chapter 8.2, but chapter 8.1.1.6 DOES > > explain what a SERVER shall do (even if the chapter itself > > describes UAC behaviour). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > Regards, > > > Hisham > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 10:58:21 2002 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 KAA08740 for ; Fri, 23 Aug 2002 10:58:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NExJQ09279 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 10:59:19 -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 g7NEw3o09162; Fri, 23 Aug 2002 10:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M3AIW23044 for ; Wed, 21 Aug 2002 23:10:18 -0400 Received: from iipc.zju.edu.cn ([210.32.156.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03603 for ; Wed, 21 Aug 2002 23:08:44 -0400 (EDT) Received: from alpha ([10.111.120.8]) by iipc.zju.edu.cn (8.9.3/8.9.3) with SMTP id UAA15459 for ; Wed, 21 Aug 2002 20:48:27 +0800 Message-Id: <200208211248.UAA15459@iipc.zju.edu.cn> From: "=?GB2312?Q?=B3=C2=C9=D0=B1=F8?=" Reply-To: sbchen@iipc.zju.edu.cn To: "sip@ietf.org" Organization: =?GB2312?Q?=D5=E3=BD=AD=B4=F3=D1=A7=CF=B5=CD=B3=B9=A4=B3=CC=D1=D0=BE=BF=CB=F9?= X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Wed, 21 Aug 2002 20:29:22 +0800 Content-Transfer-Encoding: 7bit Subject: [Sip] About the transport of 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 Hello, I have read the RFC3261 and some I-Ds, and noticed the discussions about the "SIP Congestion Safety" and "The cost of UDP ". I have some questions: 1) Who can and How to determine what trasnport protocol will be adopted when a SIP element transmit a message to next hop? 2) Besides the problems such as Congestion Control, Transport layer fragmentation, head of line blocking, etc, are there any other features worth the whistle when different transport protocols adopted? 3) In a word, I want to have a comprehensive understanding about the transport of SIP. Can you introduce some other stuffs or works to me ? Thank you! sbchen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 10:58:36 2002 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 KAA08775 for ; Fri, 23 Aug 2002 10:58:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NExZO09304 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 10:59: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 g7NEwNo09190; Fri, 23 Aug 2002 10:58: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 g7MJdWo13776 for ; Thu, 22 Aug 2002 15:39:32 -0400 Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07984 for ; Thu, 22 Aug 2002 15:38:01 -0400 (EDT) Received: from pcwhitson (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id PAA12547 for ; Thu, 22 Aug 2002 15:38:50 -0400 (EDT) From: "Doug Whitson" To: Date: Thu, 22 Aug 2002 15:40:02 -0400 Message-ID: <000001c24a13$b6c6a160$e22119ac@ulticom.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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] bnf problem with 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: 7bit Hello, Torture test file msg8_invite has a Subject header that looks like the following : Subject :^M NewFangledHeader: newfangled value^M more newfangled value^M Content-Type: application/sdp^M Following the ABNF for subject, Content-Type is recognized as part of the subject header itself, rather then a seprate sip header since the TEXT_UTF8 ABNF encompasses content-type. Please let me know if this is a problem with the abnf or not. ------------------------------------------------------------- Thank you. Doug Whitson Senior Software Engineer Ulticom Inc. 1020 Briggs Road, Mt Laurel NJ, 08054 (856)787-2927 whitson@ulticom.com In seeking wisdom, the first step is silence, the second listening, the third remembering, the fourth practicing, the fifth -- teaching others. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 10:58:37 2002 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 KAA08778 for ; Fri, 23 Aug 2002 10:58:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NExZx09316 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 10:59: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 g7NEwVo09209; Fri, 23 Aug 2002 10:58: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 g7MKeAo17516 for ; Thu, 22 Aug 2002 16:40:10 -0400 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09857 for ; Thu, 22 Aug 2002 16:38:38 -0400 (EDT) Received: from MLEITE-W2K2.cisco.com (dhcp-64-100-177-92.cisco.com [64.100.177.92]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id NAA20540 for ; Thu, 22 Aug 2002 13:39:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20020822173559.0273b000@franklin.cisco.com> X-Sender: mleite@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Aug 2002 17:38:19 +0100 To: sip@ietf.org From: Marcelo Leite Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_32069463==_.ALT" Subject: [Sip] Interworking between SIP/MFC-R2 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: , --=====================_32069463==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Is the IETF working on a document describing the interworking between SIP=20 events and MFC-R2 signals ? Thanks in advance, Marcelo Leite. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marcelo Leite (mleite@cisco.com) Systems Engineer Cisco do Brasil=20 Ltda. |=20 | | | Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares | |= =20 | | | | Barra da Tijuca - Rio de Janeiro -=20 RJ | | |=20 | | | | | CEP:=20 22640-102 Brasil=20 | | | | | | | | | | Phone:=20 55+21 2483-6365=20 | | | | | | | | | | | | | | Fax: 55+21=20 2483-6399=20 ...:| | | | | | | |:.. ...:| | | | | | | |:... Mobile: 55 +21 93329949 = Cisco=20 Systems = Changing=20 the way we work, live, play and learn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----------------------------------------------------------------------------= ---------------------- NETWORKERS 2002 - BUENOS AIRES A Conferencia Anual para usuarios da Cisco Systems 12 a 15 de Novembro de 2002 Hotel Hilton, Buenos Aires, Argentina http://www.cisco.com/ar/networkers ----------------------------------------------------------------------------= ---------------------- --=====================_32069463==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is the IETF working on a document describing the interworking between SIP events and MFC-R2 signals ?

Thanks in advance,

Marcelo Leite.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Marcelo Leite (mleite@cisco.com)
Systems Engineer
Cisco do Brasil Ltda.            = ;            &nb= sp;            &= nbsp;            = ;    | |                   | |
Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares           &nb= sp;            &= nbsp; | | |            &nb= sp;           | | |
Barra da Tijuca - Rio de Janeiro - RJ            &n= bsp;            =             &nbs= p;      | | | |                       | | | |
CEP: 22640-102  Brasil           &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;   | | | | |                     | | | | |
Phone: 55+21  2483-6365           &= nbsp;            = ;            &nb= sp;            &= nbsp;           | | | | | | |                | | | | | | |
Fax: 55+21 2483-6399           &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; ...:| | | | | | | |:..       ...:| | | | | | | |:...
Mobile: 55 +21 93329949           &n= bsp;            =        

            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;         Cisco Systems
       &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             Changing the way we work, live= , play and learn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

----------------------------------------------------------------------------= ----------------------
NETWORKERS 2002 - BUENOS AIRES
A Conferencia Anual para usuarios da Cisco Systems
            &nbs= p;   12 a 15 de Novembro de 2002
             Hotel Hilton, Buenos Aires, Argentina
            &nbs= p;  http://www.cisco.com/ar/networkers
---------------------------------------------------------------------= -----------------------------
--=====================_32069463==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 10:58:53 2002 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 KAA08805 for ; Fri, 23 Aug 2002 10:58:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NExp309331 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 10:59: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 g7NEweo09229; Fri, 23 Aug 2002 10:58: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 g7MLD2o19617 for ; Thu, 22 Aug 2002 17:13:02 -0400 Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11080 for ; Thu, 22 Aug 2002 17:11:31 -0400 (EDT) Received: from pcwhitson (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id RAA29844 for ; Thu, 22 Aug 2002 17:12:26 -0400 (EDT) From: "Doug Whitson" To: Date: Thu, 22 Aug 2002 17:13:39 -0400 Message-ID: <000001c24a20$c998d300$e22119ac@ulticom.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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] followup email 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, My earlier email may not have been exact. It seems all open ended headers, ie: extensions, organization, and subject have the same trouble. The parser needs to know when to stop parsing these headers and since they may span multiple \r\n this cannot be used as a end sequence. I am thinking a subject-length and the like may be required. Please let me know your thoughts... ------------------------------------------------------------- Thank you. Doug Whitson Senior Software Engineer Ulticom Inc. 1020 Briggs Road, Mt Laurel NJ, 08054 (856)787-2927 whitson@ulticom.com In seeking wisdom, the first step is silence, the second listening, the third remembering, the fourth practicing, the fifth -- teaching others. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 13:48:32 2002 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 NAA12878 for ; Fri, 23 Aug 2002 13:48:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NHnXn19092 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 13:49:33 -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 g7NHmso19073; Fri, 23 Aug 2002 13:48: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 g7NHjAo19016 for ; Fri, 23 Aug 2002 13:45:10 -0400 Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12833 for ; Fri, 23 Aug 2002 13:43:38 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7NHhjrx025474; Fri, 23 Aug 2002 13:43:45 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 12:44:15 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64086@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Christer Holmberg'" , hisham.khartabil@nokia.com Cc: sip@ietf.org Subject: RE: [Sip] Max-Forward checking at UAS Date: Fri, 23 Aug 2002 12:44:14 -0500 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: , > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > The UAS could check the Via branch-id, to see if the > Max-Forwards header is mandatory for that specific message or > not. The UAS will have to check the branch-id it anyway, to > find out if it is able to use it as > transaction identifier, or if it will have to do it the "old > way" (ie using CSeq, Call-ID, etc) My understanding is that the branch-id magic cookie only defines that the branch-id itself is sufficient for use as a transaction ID, and that it doesn't imply anything else about any other handling. If we wanted a global token for saying "I do everything according to RFC3261, and exhibit no RFC2543 behavior," that would be better acheived by changing the version to SIP/2.1. In my opinion, assuming that the presence of the branch parameter magic cookie has any bearing on anything more than the spec claims (which is *only* that it can be used for a transaction ID) is begging for articifical interoperablility limitations. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 23 13:57:34 2002 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 NAA13103 for ; Fri, 23 Aug 2002 13:57:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NHwXk19294 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 13:58:33 -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 g7NHwDo19284; Fri, 23 Aug 2002 13:58: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 g7NHvGo19248 for ; Fri, 23 Aug 2002 13:57:16 -0400 Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13055 for ; Fri, 23 Aug 2002 13:55:47 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7NHterx025555; Fri, 23 Aug 2002 13:55:40 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 12:56:10 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64087@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Doug Whitson'" , sip@ietf.org Subject: RE: [Sip] followup email Date: Fri, 23 Aug 2002 12:56:09 -0500 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: , Your end sequence is \r\n followed by anything that is not a tab or a space. Please read RFC3261, section 7.3 and its subsections. Any further implementation questions should go to sip-implementors@cs.columbia.edu, as noted at the bottom of every single note posted to this list. /a > -----Original Message----- > From: Doug Whitson [mailto:douglas.whitson@ulticom.com] > Sent: Thursday, August 22, 2002 16:14 > To: sip@ietf.org > Subject: [Sip] followup email > > > Hi, > My earlier email may not have been exact. It seems all open > ended headers, > ie: extensions, organization, and subject have the same > trouble. The parser > needs to know when to stop parsing these headers and since > they may span > multiple \r\n this cannot be used as a end sequence. I am thinking a > subject-length and the like may be required. > > Please let me know your thoughts... > > > ------------------------------------------------------------- > Thank you. > > Doug Whitson > Senior Software Engineer > Ulticom Inc. > 1020 Briggs Road, Mt Laurel NJ, 08054 > (856)787-2927 > whitson@ulticom.com > > In seeking wisdom, the first step is silence, the second > listening, the > third remembering, the fourth practicing, the fifth -- > teaching others. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 23 14:10:03 2002 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 OAA13397 for ; Fri, 23 Aug 2002 14:10:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NIB2k20120 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 14:11: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 g7NIAKo20094; Fri, 23 Aug 2002 14:10: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 g7NI9co20058 for ; Fri, 23 Aug 2002 14:09:38 -0400 Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13362 for ; Fri, 23 Aug 2002 14:08:08 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g7NCJJ120773; Fri, 23 Aug 2002 07:19:19 -0500 Subject: RE: [Sip] Max-Forward checking at UAS From: Robert Sparks To: Adam Roach Cc: "'Christer Holmberg'" , hisham.khartabil@nokia.com, sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64086@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A64086@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 23 Aug 2002 13:05:52 -0500 Message-Id: <1030125957.1356.54.camel@dhcp116.dfw.dynamicsoft.com> Mime-Version: 1.0 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 strongly agree with Adam on this point. "z9hG4bK" should only be taken to mean that the remainder is safe to use as a transaction identifier. Basing decisions on processing other parts of a message on its presence or absence is a strong invitation for surprising behavior. Now - to the original point of the thread: The point of Max-Forward is to prevent arbitrary propagation of requests. An endpoint is not going to propagate the request, so having an endpoint reject the request because the header is not present would be pointlessly pedantic. Having it reject the request because it had a value of 0 is a poor choice as well - the request is where it was supposed to be, so go ahead and operate on it. Postel's Maxim alone is enough here - as far as I can tell, there is no value in an endpoint even bothering to _look_ for a Max-Forward header field in a received request, so it should just ignore it, even if it is absent. RjS On Fri, 2002-08-23 at 12:44, Adam Roach wrote: > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > The UAS could check the Via branch-id, to see if the > > Max-Forwards header is mandatory for that specific message or > > not. The UAS will have to check the branch-id it anyway, to > > find out if it is able to use it as > > transaction identifier, or if it will have to do it the "old > > way" (ie using CSeq, Call-ID, etc) > > My understanding is that the branch-id magic cookie only defines > that the branch-id itself is sufficient for use as a transaction > ID, and that it doesn't imply anything else about any other handling. > > If we wanted a global token for saying "I do everything according > to RFC3261, and exhibit no RFC2543 behavior," that would be better > acheived by changing the version to SIP/2.1. > > In my opinion, assuming that the presence of the branch parameter > magic cookie has any bearing on anything more than the spec claims > (which is *only* that it can be used for a transaction ID) is begging > for articifical interoperablility limitations. > > /a > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 23 17:17:18 2002 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 RAA17947 for ; Fri, 23 Aug 2002 17:17:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NLIKP29142 for sip-archive@odin.ietf.org; Fri, 23 Aug 2002 17:18: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 g7NLDno29031; Fri, 23 Aug 2002 17:13: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 g7NLCxo29003 for ; Fri, 23 Aug 2002 17:12:59 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17874 for ; Fri, 23 Aug 2002 17:11:26 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7NLCFW4018688; Fri, 23 Aug 2002 14:12:15 -0700 (PDT) Received: from open-131-161-248-87.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAT12843; Fri, 23 Aug 2002 14:10:35 -0700 (PDT) Date: Fri, 23 Aug 2002 14:12:38 -0700 Subject: Re: [Sip] Mandatory header changed in response Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Jonathan Rosenberg , Medhavi Bhatia , hisham.khartabil@nokia.com, sip@ietf.org To: Christer Holmberg From: Rohan Mahy In-Reply-To: <3D660E1A.E3EA9909@lmf.ericsson.se> Message-Id: <0DA570AB-B6DD-11D6-A406-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) 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 On Friday, August 23, 2002, at 03:27 AM, Christer Holmberg wrote: > > Hi, > >> The spec is clear on how responses are constructed, and that includes >> copying the CSeq and To as is, with the possible addition of a To tag. >> These are MUST strength requirements. > > Does "as is" also mean that all possible parameters must be in the same > order, and does it also mean we're not allowed to add/remove "<" and ">" > characters around the uri. no, as is means that you leave the headers (except for the addition of the To tag) *semantically* equivalent. note that this means not fiddling with the hostpart. i have seen implementations add :5060 and transport parameters and other such nonsense. based on the comparison rules in 3261, host and host:5060 are no longer equivalent. thanks, -rohan > In other words: is it required to do a byte copy of the whole header > from the > request into the response? required? no a good idea? maybe ;-) > Personally I think that would be a bad idea, since > the "url comparision" rules do NOT require that. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > >> >> >> Therefore, a UAC receiving a response that has a modified To, CSeq, or >> something else, is talking to a mis-implemented UAS. As I have stated >> many times, the spec does not attempt to prescribe behavior for every >> strange (and generally, uncorrectable) error situation, this one >> included. It is an implementation issue how you deal with it if it >> occurs, but there is no expectation of proper operation in this >> scenario. >> >> -Jonathan R. >> >> Medhavi Bhatia wrote: >>> The spec mentions that the UAS must match the headers in the response. >>> That >>> has to be done at the transaction layer of the UAS, before the >>> response >>> is >>> accepted and delivered to the core. >>> >>> I guess the transaction layer description should be updated to reflect >>> that... >>> >>> ----- Original Message ----- >>> From: >>> To: >>> Cc: >>> Sent: Tuesday, August 20, 2002 8:40 AM >>> Subject: RE: [Sip] Mandatory header changed in response >>> >>> >>> >>>> The point is that its too late to discard since the transactions >>>> layer >>> >>> accepted it and moved to the next state, so no retransmissions. >>> >>>> Its not an implementation issue when To-header gets changed in a 200 >>> >>> Ok >>> for an REGISTER, for example. Or when CSeq gets changed in 200 OK for >>> INVITE. What does Server Core do? >>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Christer Holmberg >>>> >>> [mailto:christer.holmberg@lmf.ericsson.se] >>> >>>>> Sent: Tuesday, August 20, 2002 1:05 PM >>>>> To: Khartabil Hisham (NMP/Helsinki) >>>>> Cc: sip@ietf.org >>>>> Subject: Re: [Sip] Mandatory header changed in response >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I would regard is as an implementation issue, ie you choose >>>>> if you don't care about the changed header values, or if you >>>>> discard the message etc. >>>>> >>>>> Regards, >>>>> >>>>> Christer Holmberg >>>>> Ericsson Finland >>>>> >>>>> hisham.khartabil@nokia.com wrote: >>>>> >>>>> >>>>>> Now that matching responses to requests is done using >>>>> >>>>> branch-id. How should the behaviour be when a mandatory >>>>> header has been modified in the response? >>>>> >>>>>> E.g. 1 >>>>>> >>>>>> REGISTER ... >>>>>> To: sip:hisham.khartabil@nokia.com >>>>>> Contact: sip:hisham.khartabil@pc.nokia.com >>>>>> ... >>>>>> >>>>>> 200 Ok >>>>>> To: sip:someonelese@nokia.com >>>>>> Contact: sip:hisham.khartabil@pc.nokia.com >>>>>> ... >>>>>> >>>>>> Do we accept that a binding has been created? >>>>>> >>>>>> E.g. 2 >>>>>> >>>>>> INVITE >>>>>> ... >>>>>> CSeq: 1 INVITE >>>>>> >>>>>> 200 ok >>>>>> ... >>>>>> CSeq: 15 INVITE >>>>>> >>>>>> This affects the local sequence number. Which one to store >>>>> >>>>> and use for requests within dialogs? >>>>> >>>>>> Thanks, >>>>>> Hisham >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of >>>>> >>> sip >>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@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. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> 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 Sat Aug 24 04:03:01 2002 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 EAA06605 for ; Sat, 24 Aug 2002 04:03:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7O847v29224 for sip-archive@odin.ietf.org; Sat, 24 Aug 2002 04:04: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 g7O834o29179; Sat, 24 Aug 2002 04:03: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 g7O80uo28862 for ; Sat, 24 Aug 2002 04:00:56 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06546 for ; Sat, 24 Aug 2002 03:59:19 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7O80eRb008007; Sat, 24 Aug 2002 10:00:41 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7O80da9012451; Sat, 24 Aug 2002 11:00:39 +0300 (EET DST) Message-ID: <3D673D27.20F0D8A6@lmf.ericsson.se> Date: Sat, 24 Aug 2002 11:00:39 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Adam Roach , hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Max-Forward checking at UAS References: <9BF66EBF6BEFD942915B4D4D45C051F3A64086@DYN-TX-EXCH-001.dynamicsoft.com> <1030125957.1356.54.camel@dhcp116.dfw.dynamicsoft.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, I agree with you all that the cookie should not be used to determine if the sender does things according to RFC3261 or RFC2543. However, even if you say that "z9hG4bK" means that the branch-id is "safe" to use as transaction identifier, it indirectly does indicate if the sender does things according to RFC3261 or RFC2543, doesn't it? Anyway, there is no idea to argue about that :) I also agree with Robert that at least a UAS should not care about the value of the Max-Forwards header, since the message has reached its "destination". I guess another question is what proxies do when they receive a message without the header. A few options (all implementation specific, I think, so there is no idea to define any specific behaviour in the spec): 1. The proxy doesn't care, simply forwards the message. 2. The proxy doesn't accept the message 3. The proxy INSERTS a Max-Forwards header, and forwards the message. The first and second options are not so good, since first destroys the functionality the header is supposed to provide in the first place, and the second destroys the backward compability. But, again, I assume it's an implementation issue.... Or? A test case for SIPit, Robert? Regards, Christer Holmberg Ericsson Finland Robert Sparks wrote: > I strongly agree with Adam on this point. > > "z9hG4bK" should only be taken to mean that the remainder > is safe to use as a transaction identifier. Basing decisions > on processing other parts of a message on its presence or absence > is a strong invitation for surprising behavior. > > Now - to the original point of the thread: > > The point of Max-Forward is to prevent arbitrary propagation > of requests. An endpoint is not going to propagate the request, > so having an endpoint reject the request because the header is > not present would be pointlessly pedantic. Having it reject > the request because it had a value of 0 is a poor choice as well - > the request is where it was supposed to be, so go ahead and operate > on it. > > Postel's Maxim alone is enough here - as far as I can tell, there > is no value in an endpoint even bothering to _look_ for a Max-Forward > header field in a received request, so it should just ignore it, > even if it is absent. > > RjS > > On Fri, 2002-08-23 at 12:44, Adam Roach wrote: > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > The UAS could check the Via branch-id, to see if the > > > Max-Forwards header is mandatory for that specific message or > > > not. The UAS will have to check the branch-id it anyway, to > > > find out if it is able to use it as > > > transaction identifier, or if it will have to do it the "old > > > way" (ie using CSeq, Call-ID, etc) > > > > My understanding is that the branch-id magic cookie only defines > > that the branch-id itself is sufficient for use as a transaction > > ID, and that it doesn't imply anything else about any other handling. > > > > If we wanted a global token for saying "I do everything according > > to RFC3261, and exhibit no RFC2543 behavior," that would be better > > acheived by changing the version to SIP/2.1. > > > > In my opinion, assuming that the presence of the branch parameter > > magic cookie has any bearing on anything more than the spec claims > > (which is *only* that it can be used for a transaction ID) is begging > > for articifical interoperablility limitations. > > > > /a > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@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 Aug 24 04:07:19 2002 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 EAA06698 for ; Sat, 24 Aug 2002 04:07:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7O88P129368 for sip-archive@odin.ietf.org; Sat, 24 Aug 2002 04:08: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 g7O886o29361; Sat, 24 Aug 2002 04:08:06 -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 g7O87Uo29343 for ; Sat, 24 Aug 2002 04:07:30 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06688 for ; Sat, 24 Aug 2002 04:05:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7O87DRb008351; Sat, 24 Aug 2002 10:07:13 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7O870a9013069; Sat, 24 Aug 2002 11:07:00 +0300 (EET DST) Message-ID: <3D673EA4.8D89E2F1@lmf.ericsson.se> Date: Sat, 24 Aug 2002 11:07:00 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: Jonathan Rosenberg , Medhavi Bhatia , hisham.khartabil@nokia.com, sip@ietf.org, gonzalo.camarillo@lmf.ericsson.se Subject: Re: [Sip] Mandatory header changed in response References: <0DA570AB-B6DD-11D6-A406-0003938AF740@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, > >> The spec is clear on how responses are constructed, and that includes > >> copying the CSeq and To as is, with the possible addition of a To tag. > >> These are MUST strength requirements. > > > > Does "as is" also mean that all possible parameters must be in the same > > order, and does it also mean we're not allowed to add/remove "<" and ">" > > characters around the uri. > > no, as is means that you leave the headers (except for the addition of > the To tag) *semantically* equivalent. Good. So, then I assume it's also allowed to add/remove the "<" and ">" characters, because it doesn't change the semantics. I just wanted to clarify this, because I've been involved in some private discussions about this, where there were some different opinions about it. My understanding is that Gonzalo also discussed it with some of you (the editors, that is) at that time, and assuming to him (Gonzalo, please correct me if I'm wrong :) my assumption was correct, so... Regards, Christer Holmberg Ericsson Finland > note that this means not fiddling with the hostpart. i have seen > implementations add :5060 and > transport parameters and other such nonsense. based on the comparison rules > in 3261, host and host:5060 are no longer equivalent. > > thanks, > -rohan > > > In other words: is it required to do a byte copy of the whole header > > from the > > request into the response? > > required? no > a good idea? maybe > > ;-) > > > Personally I think that would be a bad idea, since > > the "url comparision" rules do NOT require that. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > >> > >> > >> Therefore, a UAC receiving a response that has a modified To, CSeq, or > >> something else, is talking to a mis-implemented UAS. As I have stated > >> many times, the spec does not attempt to prescribe behavior for every > >> strange (and generally, uncorrectable) error situation, this one > >> included. It is an implementation issue how you deal with it if it > >> occurs, but there is no expectation of proper operation in this > >> scenario. > >> > >> -Jonathan R. > >> > >> Medhavi Bhatia wrote: > >>> The spec mentions that the UAS must match the headers in the response. > >>> That > >>> has to be done at the transaction layer of the UAS, before the > >>> response > >>> is > >>> accepted and delivered to the core. > >>> > >>> I guess the transaction layer description should be updated to reflect > >>> that... > >>> > >>> ----- Original Message ----- > >>> From: > >>> To: > >>> Cc: > >>> Sent: Tuesday, August 20, 2002 8:40 AM > >>> Subject: RE: [Sip] Mandatory header changed in response > >>> > >>> > >>> > >>>> The point is that its too late to discard since the transactions > >>>> layer > >>> > >>> accepted it and moved to the next state, so no retransmissions. > >>> > >>>> Its not an implementation issue when To-header gets changed in a 200 > >>> > >>> Ok > >>> for an REGISTER, for example. Or when CSeq gets changed in 200 OK for > >>> INVITE. What does Server Core do? > >>> > >>>> /Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Christer Holmberg > >>>> > >>> [mailto:christer.holmberg@lmf.ericsson.se] > >>> > >>>>> Sent: Tuesday, August 20, 2002 1:05 PM > >>>>> To: Khartabil Hisham (NMP/Helsinki) > >>>>> Cc: sip@ietf.org > >>>>> Subject: Re: [Sip] Mandatory header changed in response > >>>>> > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> I would regard is as an implementation issue, ie you choose > >>>>> if you don't care about the changed header values, or if you > >>>>> discard the message etc. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer Holmberg > >>>>> Ericsson Finland > >>>>> > >>>>> hisham.khartabil@nokia.com wrote: > >>>>> > >>>>> > >>>>>> Now that matching responses to requests is done using > >>>>> > >>>>> branch-id. How should the behaviour be when a mandatory > >>>>> header has been modified in the response? > >>>>> > >>>>>> E.g. 1 > >>>>>> > >>>>>> REGISTER ... > >>>>>> To: sip:hisham.khartabil@nokia.com > >>>>>> Contact: sip:hisham.khartabil@pc.nokia.com > >>>>>> ... > >>>>>> > >>>>>> 200 Ok > >>>>>> To: sip:someonelese@nokia.com > >>>>>> Contact: sip:hisham.khartabil@pc.nokia.com > >>>>>> ... > >>>>>> > >>>>>> Do we accept that a binding has been created? > >>>>>> > >>>>>> E.g. 2 > >>>>>> > >>>>>> INVITE > >>>>>> ... > >>>>>> CSeq: 1 INVITE > >>>>>> > >>>>>> 200 ok > >>>>>> ... > >>>>>> CSeq: 15 INVITE > >>>>>> > >>>>>> This affects the local sequence number. Which one to store > >>>>> > >>>>> and use for requests within dialogs? > >>>>> > >>>>>> Thanks, > >>>>>> Hisham > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>> This list is for NEW development of the core SIP Protocol > >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>>> Use sipping@ietf.org for new developments on the application of > >>>>> > >>> sip > >>> > >>>>> > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol > >>>>> Use sip-implementors@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. 72 Eagle Rock Ave. > >> Chief Scientist First Floor > >> dynamicsoft East Hanover, NJ 07936 > >> 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 Sat Aug 24 09:51:59 2002 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 JAA11028 for ; Sat, 24 Aug 2002 09:51:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7ODquX08651 for sip-archive@odin.ietf.org; Sat, 24 Aug 2002 09:52: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 g7ODpEo08619; Sat, 24 Aug 2002 09:51: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 g7ODn8o08535 for ; Sat, 24 Aug 2002 09:49:08 -0400 Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10977 for ; Sat, 24 Aug 2002 09:47:39 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H1C00801P036N@siemenscomms.co.uk> for sip@ietf.org; Sat, 24 Aug 2002 14:48:03 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H1C007KZP03CE@siemenscomms.co.uk>; Sat, 24 Aug 2002 14:48:03 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Sat, 24 Aug 2002 14:48:34 +0100 Content-return: allowed Date: Sat, 24 Aug 2002 14:46:08 +0100 From: "Elwell, John" Subject: RE: [Sip] Local vs Remote ringback on 180 To: "Ejzak, Richard P (Richard)" , "'christer.holmberg@lmf.ericsson.se'" Cc: "'sip@ietf.org'" , "'jon.peterson@neustar.biz'" Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0426C452@Beex50.siemenscomms.co.uk> 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 Richard, Yes, this seems to work (taking into account subsequent messages in this thread). John -----Original Message----- From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com] Sent: Thursday, August 22, 2002 9:19 PM To: 'Elwell, John'; 'christer.holmberg@lmf.ericsson.se' Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: RE: [Sip] Local vs Remote ringback on 180 John, As I started writing a response to your mail, another response came in from David Oliver that contains what seems to be a reasonable solution to your problem. Please allow me to refer you to David's email and my response. Regards, Richard Ejzak -----Original Message----- From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk] Sent: Thursday, August 22, 2002 9:33 AM To: 'Ejzak, Richard P (Richard)'; 'christer.holmberg@lmf.ericsson.se' Cc: 'sip@ietf.org'; 'jon.peterson@neustar.biz' Subject: RE: [Sip] Local vs Remote ringback on 180 Richard, You wrote: > The only other consideration I can think of is that this > proposal seems to make it impossible to signal an ISUP > alerting indication from a CPG within SIP once in-band call > progress has been established (in either direction). [E.g., > it precludes 180 after 183 when you don't want local ringtone > but want in-band information instead. So how do you signal > ISUP alerting after in-band call progress is established?] I > propose that for this case (which I think is only needed for > ISUP bridging), the ISUP alerting indication be optionally > passed in a MIME attachment to a 183 response rather than a > 180 response, to make it clear that the UAC should not > generate local ringtone. [This minor change should go in the > sip-isup draft.] Similarly, it does not allow us to signal a QSIG ALERTING message accompanied by in-band tone or announcement. If it is signalled as 180, local ring-back tone might be applied and the remote tone or announcement lost. If it is signalled as 183, a QSIG UAC will map to PROGRESS rather than ALERTING, and this could have implications in the originating QSIG network or at the caller's equipment. Although we could solve this QSIG-SIP-QSIG scenario by tunnelling QSIG in MIME, this solution will not work for QSIG-SIP-ISUP and ISUP-SIP-QSIG scenarios. I made this point a few days ago on the SIPPING thread and have not had an answer. John -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 02:57:43 2002 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 CAA02232 for ; Mon, 26 Aug 2002 02:57:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7Q6wpV16571 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 02:58: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 g7Q6w9o16557; Mon, 26 Aug 2002 02:58: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 g7Q6tLo16463 for ; Mon, 26 Aug 2002 02:55:21 -0400 Received: from mta1 ([61.144.161.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02199 for ; Mon, 26 Aug 2002 02:53:41 -0400 (EDT) Received: from himanshoo (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H1F00KU7V5JCD@mta1.huawei.com> for sip@ietf.org; Mon, 26 Aug 2002 14:53:44 +0800 (CST) Date: Mon, 26 Aug 2002 14:56:32 +0800 From: "Himanshoo Kumar Saxena (LongGang)" To: sip@ietf.org Reply-to: "Himanshoo Kumar Saxena (LongGang)" Message-id: <001401c24ccd$b65b7950$7f984c0a@himanshoo> Organization: Hua Wei, LongGang , China MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_Prf3B6UBTiVHEBCmCdPDAA)" X-Priority: 3 X-MSMail-priority: Normal References: <0DA570AB-B6DD-11D6-A406-0003938AF740@cisco.com> <3D673EA4.8D89E2F1@lmf.ericsson.se> Subject: [Sip] some info on SIP presence service 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_Prf3B6UBTiVHEBCmCdPDAA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, I am looking for some information on implementing Presnce service using SIP... Can anyone help me locate correct RFC/standards. Best Regards ---------------------------------------------------------- Himanshoo Kumar Saxena IN service department Huawei Technologies Company Limited Long Gang District Shenzhen - 518000 P.R.China Ph: +86-755-28788924(Off) --Boundary_(ID_Prf3B6UBTiVHEBCmCdPDAA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
I am looking for some information on implementing Presnce service using SIP... Can anyone help me locate correct RFC/standards.
 
Best Regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Long Gang District
Shenzhen - 518000
P.R.China
Ph: +86-755-28788924(Off)
--Boundary_(ID_Prf3B6UBTiVHEBCmCdPDAA)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 04:31:58 2002 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 EAA03673 for ; Mon, 26 Aug 2002 04:31:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7Q8X5S21207 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 04:33: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 g7Q8VGo21125; Mon, 26 Aug 2002 04:31: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 g7Q8TTo21045 for ; Mon, 26 Aug 2002 04:29:29 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03570 for ; Mon, 26 Aug 2002 04:27:50 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7Q8fef00182 for ; Mon, 26 Aug 2002 11:41:40 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Aug 2002 11:29:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 26 Aug 2002 11:29:15 +0300 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" Subject: RE: [Sip] Max-Forward checking at UAS Date: Mon, 26 Aug 2002 11:29:13 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2051B@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Max-Forward checking at UAS Thread-Index: AcJLRFlmE71KrpqKQiy6OYVdJVTKHQBldlcg To: , Cc: , X-OriginalArrivalTime: 26 Aug 2002 08:29:15.0720 (UTC) FILETIME=[A9EC1C80:01C24CDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7Q8TTo21046 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 > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Saturday, August 24, 2002 11:01 AM > To: Robert Sparks > Cc: Adam Roach; Khartabil Hisham (NMP/Helsinki); sip@ietf.org > Subject: Re: [Sip] Max-Forward checking at UAS > > > > Hi, > > I agree with you all that the cookie should not be used to > determine if the > sender does things according to RFC3261 or RFC2543. However, > even if you > say that "z9hG4bK" means that the branch-id is "safe" to use > as transaction > identifier, it indirectly does indicate if the sender does > things according > to RFC3261 or RFC2543, doesn't it? Anyway, there is no idea > to argue about > that :) > > I also agree with Robert that at least a UAS should not care about the > value of the Max-Forwards header, since the message has reached its > "destination". I guess another question is what proxies do when they > receive a message without the header. A few options (all > implementation > specific, I think, so there is no idea to define any specific > behaviour in > the spec): > > 1. The proxy doesn't care, simply forwards the message. > 2. The proxy doesn't accept the message > 3. The proxy INSERTS a Max-Forwards header, and forwards the message. > > The first and second options are not so good, since first destroys the > functionality the header is supposed to provide in the first > place, and the > second destroys the backward compability. Option 3 is already in RFC3261. /Hisham > > But, again, I assume it's an implementation issue.... Or? > > A test case for SIPit, Robert? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Robert Sparks wrote: > > > I strongly agree with Adam on this point. > > > > "z9hG4bK" should only be taken to mean that the remainder > > is safe to use as a transaction identifier. Basing decisions > > on processing other parts of a message on its presence or absence > > is a strong invitation for surprising behavior. > > > > Now - to the original point of the thread: > > > > The point of Max-Forward is to prevent arbitrary propagation > > of requests. An endpoint is not going to propagate the request, > > so having an endpoint reject the request because the header is > > not present would be pointlessly pedantic. Having it reject > > the request because it had a value of 0 is a poor choice as well - > > the request is where it was supposed to be, so go ahead and operate > > on it. > > > > Postel's Maxim alone is enough here - as far as I can tell, there > > is no value in an endpoint even bothering to _look_ for a > Max-Forward > > header field in a received request, so it should just ignore it, > > even if it is absent. > > > > RjS > > > > On Fri, 2002-08-23 at 12:44, Adam Roach wrote: > > > > -----Original Message----- > > > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > The UAS could check the Via branch-id, to see if the > > > > Max-Forwards header is mandatory for that specific message or > > > > not. The UAS will have to check the branch-id it anyway, to > > > > find out if it is able to use it as > > > > transaction identifier, or if it will have to do it the "old > > > > way" (ie using CSeq, Call-ID, etc) > > > > > > My understanding is that the branch-id magic cookie only defines > > > that the branch-id itself is sufficient for use as a transaction > > > ID, and that it doesn't imply anything else about any > other handling. > > > > > > If we wanted a global token for saying "I do everything according > > > to RFC3261, and exhibit no RFC2543 behavior," that would be better > > > acheived by changing the version to SIP/2.1. > > > > > > In my opinion, assuming that the presence of the branch parameter > > > magic cookie has any bearing on anything more than the spec claims > > > (which is *only* that it can be used for a transaction > ID) is begging > > > for articifical interoperablility limitations. > > > > > > /a > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@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 Aug 26 04:47:36 2002 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 EAA03949 for ; Mon, 26 Aug 2002 04:47:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7Q8miC22195 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 04:48: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 g7Q8mGo22176; Mon, 26 Aug 2002 04:48: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 g7Q8lNo22120 for ; Mon, 26 Aug 2002 04:47:23 -0400 Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03913 for ; Mon, 26 Aug 2002 04:45:36 -0400 (EDT) From: seshashayi@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g7Q8bRm20611; Mon, 26 Aug 2002 14:07:31 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C21.00300E95 ; Mon, 26 Aug 2002 14:14:54 +0530 X-Lotus-FromDomain: HSSBLR To: "Himanshoo Kumar Saxena (LongGang)" cc: sip@ietf.org Message-ID: <65256C21.00300DC5.00@sampark.hss.hns.com> Date: Mon, 26 Aug 2002 14:14:52 +0530 Subject: Re: [Sip] some info on SIP presence service Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=kfHs9Yx9ASP5Smso5ZaJqN0mFurUovl0g8lMZcqN2uTcsKiI8SeLnrhS" Content-Disposition: inline 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: , --0__=kfHs9Yx9ASP5Smso5ZaJqN0mFurUovl0g8lMZcqN2uTcsKiI8SeLnrhS Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The drafts related to SIP and presence are under simple,impp working groups: http://www.ietf.org/ids.by.wg/simple.html http://www.ietf.org/ids.by.wg/impp.html Rgds Seshu ------------------------------- http://www.hssworld.com "Himanshoo Kumar Saxena (LongGang)" on 08/26/2002 01:26:32 PM Please respond to "Himanshoo Kumar Saxena (LongGang)" To: sip@ietf.org cc: (bcc: Seshashayi T/HSSBLR) Subject: [Sip] some info on SIP presence service Hi, I am looking for some information on implementing Presnce service using SIP... Can anyone help me locate correct RFC/standards. Best Regards ---------------------------------------------------------- Himanshoo Kumar Saxena IN service department Huawei Technologies Company Limited Long Gang District Shenzhen - 518000 P.R.China Ph: +86-755-28788924(Off) --0__=kfHs9Yx9ASP5Smso5ZaJqN0mFurUovl0g8lMZcqN2uTcsKiI8SeLnrhS Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5IaSw8 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5JIGFtIGxvb2tpbmcgZm9yIHNvbWUgaW5mb3JtYXRpb24gb24gaW1wbGVtZW50aW5nIA0K UHJlc25jZSBzZXJ2aWNlIHVzaW5nIFNJUC4uLiBDYW4gYW55b25lIGhlbHAgbWUgbG9jYXRlIGNv cnJlY3QgDQpSRkMvc3RhbmRhcmRzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkJlc3QgUmVnYXJkczwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPkhpbWFuc2hvbyANCkt1bWFyIFNheGVu YTxCUj5JTiBzZXJ2aWNlIGRlcGFydG1lbnQ8QlI+SHVhd2VpIFRlY2hub2xvZ2llcyBDb21wYW55 IA0KTGltaXRlZDxCUj5Mb25nIEdhbmcgRGlzdHJpY3Q8QlI+U2hlbnpoZW4gLSA1MTgwMDA8QlI+ UC5SLkNoaW5hPEJSPlBoOiANCis4Ni03NTUtMjg3ODg5MjQoT2ZmKTwvRk9OVD48L0RJVj48L0JP RFk+PC9IVE1MPg0KDQo= --0__=kfHs9Yx9ASP5Smso5ZaJqN0mFurUovl0g8lMZcqN2uTcsKiI8SeLnrhS-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 07:53:43 2002 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 HAA06474 for ; Mon, 26 Aug 2002 07:53:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QBsga29462 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 07:54: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 g7QBsBo29453; Mon, 26 Aug 2002 07:54: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 g7QBn6o29337 for ; Mon, 26 Aug 2002 07:49:06 -0400 Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06376 for ; Mon, 26 Aug 2002 07:47:36 -0400 (EDT) Received: from jku2.iptel.org (port-212-202-171-220.reverse.qdsl-home.de [212.202.171.220]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g7QBmFU21111; Mon, 26 Aug 2002 13:48:15 +0200 Message-Id: <5.1.0.14.0.20020826132044.0314ce58@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 26 Aug 2002 13:47:50 +0200 To: "Dean Willis" , From: Jiri Kuthan Subject: RE: [Sip] SIP Traceroute using Max-Forwards In-Reply-To: <006f01c2479a$185933b0$c30c0c42@TXDWILLIS2> References: 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 Dean and anyone else looking at this discusssion. Thanks to Nils Ohlmeier, there is now beta-version of *running code* that implements the traceroute functionality. http://developer.berlios.de/projects/sipsak/ It behaves very much like IP traceroute. It sends OPTIONS requests with increasing Max-Forwards until something else than 483 or provisional is received. It displays server name if a downstream server discloses it in Warning header field. I too believe there is a need for richer status reporting. Embedding standardized diagnostic information in SIP replies would be very useful for network trouble-shooting. If things go wrong and a negative reply comes back, an upstream client knows very little now: - it does not know who generated the reply (the server might be well hidden in a deep proxy chain and Warnings are optional) - we do not know which r-uri caused a reply (it might have been rewritten couple of times) - we do not know the hop which last relayed our request to the replying server (and might be possibly guilty of troubles) -Jiri At 06:04 PM 8/19/2002, Dean Willis wrote: >> If you want to diagnose a network failure and >> pinpoint the source of the failure, OPTIONS is >> somewhat lacking. > >If you want to diagnose a network failure and >pinpoint the source of the failure, SIP is >somewhat lacking. It's easily fixed in single >oerator environments by adding some "Kilroy >Was Here" type headers in responses. > >I think it would be a good exercise to look at >the requirements for this sort of thing (over in >SIPPING) and see if we can move towards a nice, >safe, and secure way of solving the general class >problem. > >-- >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 -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 10:28:38 2002 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 KAA09152 for ; Mon, 26 Aug 2002 10:28:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QETdK03684 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 10:29: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 g7QERno03629; Mon, 26 Aug 2002 10:27: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 g7QEQuo03552 for ; Mon, 26 Aug 2002 10:26:56 -0400 Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09075; Mon, 26 Aug 2002 10:25:23 -0400 (EDT) From: aroychow@hss.hns.com Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7QEQAJ12209; Mon, 26 Aug 2002 10:26:10 -0400 (EDT) To: Jiri Kuthan Cc: "Dean Willis" , sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] SIP Traceroute using Max-Forwards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 26 Aug 2002 10:26:08 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/26/2002 10:24:14 AM, Serialize complete at 08/26/2002 10:24:14 AM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com g7QEQAJ12209 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 have just posted a small ID that attempts to capture the requirements based on our discussion in the list. Its pretty much in initial stage, but its a start. Till it appears on the list, you could find it at (hold your breath - the link is a mile long ) http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhury-sipping-pathtrace-reqts-00.txt?bcrJka9AQILo3Pai Comments welcome. One of the questions is whether we need to look at it as purely a 'diagnostic' requirement or whether we should generalize it to a 'path information' (which may include diagnostics, capabilities, etc) requirement. regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Jiri Kuthan Sent by: sip-admin@ietf.org 08/26/2002 07:47 AM To: "Dean Willis" , cc: Subject: RE: [Sip] SIP Traceroute using Max-Forwards Hi Dean and anyone else looking at this discusssion. Thanks to Nils Ohlmeier, there is now beta-version of *running code* that implements the traceroute functionality. http://developer.berlios.de/projects/sipsak/ It behaves very much like IP traceroute. It sends OPTIONS requests with increasing Max-Forwards until something else than 483 or provisional is received. It displays server name if a downstream server discloses it in Warning header field. I too believe there is a need for richer status reporting. Embedding standardized diagnostic information in SIP replies would be very useful for network trouble-shooting. If things go wrong and a negative reply comes back, an upstream client knows very little now: - it does not know who generated the reply (the server might be well hidden in a deep proxy chain and Warnings are optional) - we do not know which r-uri caused a reply (it might have been rewritten couple of times) - we do not know the hop which last relayed our request to the replying server (and might be possibly guilty of troubles) -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 10:47:19 2002 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 KAA09595 for ; Mon, 26 Aug 2002 10:47:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QEmJn04767 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 10:48:19 -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 g7QElYo04742; Mon, 26 Aug 2002 10:47:34 -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 g7QEkro04712 for ; Mon, 26 Aug 2002 10:46:53 -0400 Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09557 for ; Mon, 26 Aug 2002 10:45:18 -0400 (EDT) Message-Id: <200208261445.KAA09557@ietf.org> Received: (qmail 8628 invoked from network); 26 Aug 2002 15:03:20 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 26 Aug 2002 15:03:20 -0000 Date: Mon, 26 Aug 2002 22:54:33 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g7QEkro04713 Subject: [Sip] What should do? 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, Look at the scenarios below: 1) User A Stateful Proxy User B | | | |-----1.INVITE--------->| | | |------2.INVITE---------->| |<----3. 100------------| | | |<------4. 100------------| | | | |-----5.CANCEL--------->| <--200 OK-----| NOTE that , Stateful Proxy has received "CANCEL", at the same time User B's "200 OK" is on the line, and Proxy has not received it. For stateful proxy has received User A's "CANCEL", so it forwords "CANCEL" request to User B. But once it sends "CANCEL", User B's "200 OK" arrives. NOW, what should the proxy do? and what should User B do? User B has just sent "200 OK", then he/she will receive "CANCEL" 2) User A Stateful Proxy User B | | | |-----1.INVITE--------->| | | |------2.INVITE---------->| |<----3. 100------------| | | |<------4. 100------------| | | | |-----5.CANCEL--------->|<-------------200 OK-----| Here, AT THE SAME TIME Stateful Proxy receives User A's "CANCEL" AND User B's "200 OK", what should Proxy do then? 3) User A Stateful Proxy User B | | | |-----1.INVITE--------->| | | |------2.INVITE---------->| |<----3. 100------------| | | |<------4. 100------------| | | | |-----5.CANCEL---> |<-------------200 OK-----| Here, User A's "CANCEL" is on the line, while stateful proxy has recieved User B's 200 OK, proxy should forward this 200 OK, but when it has forwarded the 200 OK, it receives User A's "CANCEL", then , what should proxy do? And User A will receive User B's 200 OK after the "CANCEL" request, what should User A do ? Thanks a lot to give me an answer1 Best Regards. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 11:13:07 2002 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 LAA10612 for ; Mon, 26 Aug 2002 11:13:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QFE8u05944 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 11:14: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 g7QFDNo05913; Mon, 26 Aug 2002 11:13: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 g7QFCOo05869 for ; Mon, 26 Aug 2002 11:12:24 -0400 Received: from goliath.cnchost.com (goliath.cnchost.com [207.155.252.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10517; Mon, 26 Aug 2002 11:10:53 -0400 (EDT) Received: from laptopeng3 ([207.113.13.1]) by goliath.cnchost.com id LAA07904; Mon, 26 Aug 2002 11:11:08 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <006801c24d12$ec142b10$1fe4b4cc@laptopeng3> From: "Medhavi Bhatia" To: , "Jiri Kuthan" Cc: "Dean Willis" , , References: Subject: Re: [Sip] SIP Traceroute using Max-Forwards Date: Mon, 26 Aug 2002 11:10:57 -0400 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.50.4522.1200 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 Arjun, I was thinking more about the mechanism to do this, and what others think about the following idea, as a requirement/implementation: If a proxy modifies or adds a header in a request forwarded by it ( this includes forking), it adds that information (or the modified header), in a special container header/body of some sort. I think a simple thing like that may capture a lot of things for diagnostic purposes. -Medhavi. ----- Original Message ----- From: To: "Jiri Kuthan" Cc: "Dean Willis" ; ; Sent: Monday, August 26, 2002 10:26 AM Subject: RE: [Sip] SIP Traceroute using Max-Forwards I have just posted a small ID that attempts to capture the requirements based on our discussion in the list. Its pretty much in initial stage, but its a start. Till it appears on the list, you could find it at (hold your breath - the link is a mile long ) http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhury-sipping-pat htrace-reqts-00.txt?bcrJka9AQILo3Pai Comments welcome. One of the questions is whether we need to look at it as purely a 'diagnostic' requirement or whether we should generalize it to a 'path information' (which may include diagnostics, capabilities, etc) requirement. regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Jiri Kuthan Sent by: sip-admin@ietf.org 08/26/2002 07:47 AM To: "Dean Willis" , cc: Subject: RE: [Sip] SIP Traceroute using Max-Forwards Hi Dean and anyone else looking at this discusssion. Thanks to Nils Ohlmeier, there is now beta-version of *running code* that implements the traceroute functionality. http://developer.berlios.de/projects/sipsak/ It behaves very much like IP traceroute. It sends OPTIONS requests with increasing Max-Forwards until something else than 483 or provisional is received. It displays server name if a downstream server discloses it in Warning header field. I too believe there is a need for richer status reporting. Embedding standardized diagnostic information in SIP replies would be very useful for network trouble-shooting. If things go wrong and a negative reply comes back, an upstream client knows very little now: - it does not know who generated the reply (the server might be well hidden in a deep proxy chain and Warnings are optional) - we do not know which r-uri caused a reply (it might have been rewritten couple of times) - we do not know the hop which last relayed our request to the replying server (and might be possibly guilty of troubles) -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@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 Aug 26 11:21:43 2002 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 LAA10873 for ; Mon, 26 Aug 2002 11:21:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QFMh706217 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 11:22: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 g7QFMNo06203; Mon, 26 Aug 2002 11:22: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 g7QFLjo06137 for ; Mon, 26 Aug 2002 11:21:45 -0400 Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10831; Mon, 26 Aug 2002 11:20:15 -0400 (EDT) From: aroychow@hss.hns.com Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7QFKVJ01798; Mon, 26 Aug 2002 11:20:31 -0400 (EDT) To: "Medhavi Bhatia" Cc: "Dean Willis" , "Jiri Kuthan" , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] SIP Traceroute using Max-Forwards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 26 Aug 2002 11:20:29 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 08/26/2002 11:18:34 AM, Serialize complete at 08/26/2002 11:18:34 AM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com g7QFKVJ01798 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: , Medhavi, I had a similar thought on the implementation. The 'traceroute' functionality could be introducted by a header such as 'Trace-Route:'. In addition, an XML scheme could be defined for the body to encapsulate 'richer' information. However, from the initial discussion we had on the list, it seemed there may be a need to see the scope of the overall requirement and analyze if we need anything more than a traceroute. Hence the requirements before the specific implementation. Your comments would be welcome. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 "Medhavi Bhatia" 08/26/2002 11:10 AM To: aroychow@hss.hns.com, "Jiri Kuthan" cc: "Dean Willis" , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] SIP Traceroute using Max-Forwards Arjun, I was thinking more about the mechanism to do this, and what others think about the following idea, as a requirement/implementation: If a proxy modifies or adds a header in a request forwarded by it ( this includes forking), it adds that information (or the modified header), in a special container header/body of some sort. I think a simple thing like that may capture a lot of things for diagnostic purposes. -Medhavi. ----- Original Message ----- From: To: "Jiri Kuthan" Cc: "Dean Willis" ; ; Sent: Monday, August 26, 2002 10:26 AM Subject: RE: [Sip] SIP Traceroute using Max-Forwards I have just posted a small ID that attempts to capture the requirements based on our discussion in the list. Its pretty much in initial stage, but its a start. Till it appears on the list, you could find it at (hold your breath - the link is a mile long ) http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhury-sipping-pat htrace-reqts-00.txt?bcrJka9AQILo3Pai Comments welcome. One of the questions is whether we need to look at it as purely a 'diagnostic' requirement or whether we should generalize it to a 'path information' (which may include diagnostics, capabilities, etc) requirement. regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Jiri Kuthan Sent by: sip-admin@ietf.org 08/26/2002 07:47 AM To: "Dean Willis" , cc: Subject: RE: [Sip] SIP Traceroute using Max-Forwards Hi Dean and anyone else looking at this discusssion. Thanks to Nils Ohlmeier, there is now beta-version of *running code* that implements the traceroute functionality. http://developer.berlios.de/projects/sipsak/ It behaves very much like IP traceroute. It sends OPTIONS requests with increasing Max-Forwards until something else than 483 or provisional is received. It displays server name if a downstream server discloses it in Warning header field. I too believe there is a need for richer status reporting. Embedding standardized diagnostic information in SIP replies would be very useful for network trouble-shooting. If things go wrong and a negative reply comes back, an upstream client knows very little now: - it does not know who generated the reply (the server might be well hidden in a deep proxy chain and Warnings are optional) - we do not know which r-uri caused a reply (it might have been rewritten couple of times) - we do not know the hop which last relayed our request to the replying server (and might be possibly guilty of troubles) -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 11:25:36 2002 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 LAA11060 for ; Mon, 26 Aug 2002 11:25:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QFQaw06332 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 11:26: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 g7QFP9o06307; Mon, 26 Aug 2002 11:25: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 g7QFOmo06277 for ; Mon, 26 Aug 2002 11:24:48 -0400 Received: from uni00mr.unity.ncsu.edu (uni00mr.unity.ncsu.edu [152.1.1.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11011 for ; Mon, 26 Aug 2002 11:23:17 -0400 (EDT) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni00mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020819.01) with SMTP id g7QFOQ418325; Mon, 26 Aug 2002 11:24:30 -0400 (EDT) Message-ID: <093401c24d14$acd155c0$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: , References: <200208261445.KAA09557@ietf.org> Subject: Re: [Sip] What should do? Date: Mon, 26 Aug 2002 11:24:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit 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 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 comments inline.. > > Look at the scenarios below: > > 1) > > User A Stateful Proxy User B > | | | > |-----1.INVITE--------->| | > | |------2.INVITE---------->| > |<----3. 100------------| | > | |<------4. 100------------| > | | | > |-----5.CANCEL--------->| <--200 OK-----| > > NOTE that , Stateful Proxy has received "CANCEL", at the same time > > User B's "200 OK" is on the line, and Proxy has not received it. For > > stateful proxy has received User A's "CANCEL", so it forwords "CANCEL" > > request to User B. But once it sends "CANCEL", User B's "200 OK" > > arrives. NOW, what should the proxy do? and what should User B do? > > User B has just sent "200 OK", then he/she will receive "CANCEL" > Since the proxy is yet to receive the 200 OK response from User B so on receipt of a CANCEL from User A it would generate a CANCEL request of its own and send it to User B. Now the User B has already generated a final response for the original request so it would treat this CANCEL as a no-op. Thus CANCEL will have no effect. > 2) > > User A Stateful Proxy User B > | | | > |-----1.INVITE--------->| | > | |------2.INVITE---------->| > |<----3. 100------------| | > | |<------4. 100------------| > | | | > |-----5.CANCEL--------->|<-------------200 OK-----| > > Here, AT THE SAME TIME Stateful Proxy receives User A's "CANCEL" AND User B's "200 OK", > > what should Proxy do then? > Most probably CANCEL wont have any effect because a final response to INVITE has been received by the proxy. > 3) > > User A Stateful Proxy User B > | | | > |-----1.INVITE--------->| | > | |------2.INVITE---------->| > |<----3. 100------------| | > | |<------4. 100------------| > | | | > |-----5.CANCEL---> |<-------------200 OK-----| > > Here, User A's "CANCEL" is on the line, while stateful proxy has recieved > > User B's 200 OK, proxy should forward this 200 OK, but when it has forwarded > > the 200 OK, it receives User A's "CANCEL", then , what should proxy do? > > And User A will receive User B's 200 OK after the "CANCEL" request, > > what should User A do ? > Again, CANCEL would be a no-op here. User A will receive 200 OK and if he doesnt want to continue with the session then he has to send a BYE to terminate the session. Thanks, Prabhas Research Assistant Dept of Computer Engineering North Carolina State University Raleigh, NC 27695 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 11:31:47 2002 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 LAA11281 for ; Mon, 26 Aug 2002 11:31:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QFWl706527 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 11:32: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 g7QFVco06465; Mon, 26 Aug 2002 11:31: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 g7QFUEo06410 for ; Mon, 26 Aug 2002 11:30:14 -0400 Received: from goliath.cnchost.com (goliath.cnchost.com [207.155.252.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11186; Mon, 26 Aug 2002 11:28:43 -0400 (EDT) Received: from laptopeng3 ([207.113.13.1]) by goliath.cnchost.com id LAA14250; Mon, 26 Aug 2002 11:29:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <008301c24d15$718308a0$1fe4b4cc@laptopeng3> From: "Medhavi Bhatia" To: Cc: "Dean Willis" , "Jiri Kuthan" , , References: Subject: Re: [Sip] SIP Traceroute using Max-Forwards Date: Mon, 26 Aug 2002 11:29:04 -0400 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.50.4522.1200 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 Arjun, In the requirements section itself, I think we should have two levels, indicating basic support in terms of a simple set of requirements and lanother for advanced features. The whole issue of diagnostics is a very extensible idea, which will grow as the protocol develops more and more interesting functionalities. However, the routing aspects are pretty much defined right now, and diagnostics can be clearly specified. Hence my suggestion to capture the latter very simply in side a container header. -Medhavi. ----- Original Message ----- From: To: "Medhavi Bhatia" Cc: "Dean Willis" ; "Jiri Kuthan" ; ; Sent: Monday, August 26, 2002 11:20 AM Subject: Re: [Sip] SIP Traceroute using Max-Forwards Medhavi, I had a similar thought on the implementation. The 'traceroute' functionality could be introducted by a header such as 'Trace-Route:'. In addition, an XML scheme could be defined for the body to encapsulate 'richer' information. However, from the initial discussion we had on the list, it seemed there may be a need to see the scope of the overall requirement and analyze if we need anything more than a traceroute. Hence the requirements before the specific implementation. Your comments would be welcome. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 "Medhavi Bhatia" 08/26/2002 11:10 AM To: aroychow@hss.hns.com, "Jiri Kuthan" cc: "Dean Willis" , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] SIP Traceroute using Max-Forwards Arjun, I was thinking more about the mechanism to do this, and what others think about the following idea, as a requirement/implementation: If a proxy modifies or adds a header in a request forwarded by it ( this includes forking), it adds that information (or the modified header), in a special container header/body of some sort. I think a simple thing like that may capture a lot of things for diagnostic purposes. -Medhavi. ----- Original Message ----- From: To: "Jiri Kuthan" Cc: "Dean Willis" ; ; Sent: Monday, August 26, 2002 10:26 AM Subject: RE: [Sip] SIP Traceroute using Max-Forwards I have just posted a small ID that attempts to capture the requirements based on our discussion in the list. Its pretty much in initial stage, but its a start. Till it appears on the list, you could find it at (hold your breath - the link is a mile long ) http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhury-sipping-pat htrace-reqts-00.txt?bcrJka9AQILo3Pai Comments welcome. One of the questions is whether we need to look at it as purely a 'diagnostic' requirement or whether we should generalize it to a 'path information' (which may include diagnostics, capabilities, etc) requirement. regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Jiri Kuthan Sent by: sip-admin@ietf.org 08/26/2002 07:47 AM To: "Dean Willis" , cc: Subject: RE: [Sip] SIP Traceroute using Max-Forwards Hi Dean and anyone else looking at this discusssion. Thanks to Nils Ohlmeier, there is now beta-version of *running code* that implements the traceroute functionality. http://developer.berlios.de/projects/sipsak/ It behaves very much like IP traceroute. It sends OPTIONS requests with increasing Max-Forwards until something else than 483 or provisional is received. It displays server name if a downstream server discloses it in Warning header field. I too believe there is a need for richer status reporting. Embedding standardized diagnostic information in SIP replies would be very useful for network trouble-shooting. If things go wrong and a negative reply comes back, an upstream client knows very little now: - it does not know who generated the reply (the server might be well hidden in a deep proxy chain and Warnings are optional) - we do not know which r-uri caused a reply (it might have been rewritten couple of times) - we do not know the hop which last relayed our request to the replying server (and might be possibly guilty of troubles) -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 26 11:53:52 2002 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 LAA12110 for ; Mon, 26 Aug 2002 11:53:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QFsrB07709 for sip-archive@odin.ietf.org; Mon, 26 Aug 2002 11:54: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 g7QFrco07646; Mon, 26 Aug 2002 11:53: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 g7QFqso07605 for ; Mon, 26 Aug 2002 11:52:54 -0400 Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12043; Mon, 26 Aug 2002 11:51:22 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g7QFpB327840; Mon, 26 Aug 2002 10:51:11 -0500 From: "Dean Willis" To: "'Medhavi Bhatia'" , Cc: "'Jiri Kuthan'" , , Subject: RE: [Sip] SIP Traceroute using Max-Forwards Date: Mon, 26 Aug 2002 10:50:44 -0500 Message-ID: <003101c24d18$56e00130$a6036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: <008301c24d15$718308a0$1fe4b4cc@laptopeng3> 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 By the way guys -- requirements development work is done in SIPPING, right? Can we move the requirements development over there? -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Medhavi Bhatia > Sent: Monday, August 26, 2002 10:29 AM > To: aroychow@hss.hns.com > Cc: Dean Willis; Jiri Kuthan; sip@ietf.org; sip-admin@ietf.org > Subject: Re: [Sip] SIP Traceroute using Max-Forwards > > > Arjun, > > In the requirements section itself, I think we should have > two levels, indicating basic support in terms of a simple set > of requirements and lanother for advanced features. The whole > issue of diagnostics is a very extensible idea, which will > grow as the protocol develops more and more interesting > functionalities. However, the routing aspects are pretty > much defined right now, and diagnostics can be clearly > specified. Hence my suggestion to capture the latter very > simply in side a container header. > > -Medhavi. > > ----- Original Message ----- > From: > To: "Medhavi Bhatia" > Cc: "Dean Willis" ; "Jiri Kuthan" > ; ; > Sent: Monday, August 26, 2002 11:20 AM > Subject: Re: [Sip] SIP Traceroute using Max-Forwards > > > Medhavi, > I had a similar thought on the implementation. The > 'traceroute' functionality could be introducted by a header > such as 'Trace-Route:'. In addition, an XML scheme could be > defined for the body to encapsulate 'richer' information. > > However, from the initial discussion we had on the list, it > seemed there may be a need to see the scope of the overall > requirement and analyze if we need anything more than a > traceroute. Hence the requirements before the specific implementation. > > Your comments would be welcome. > > regds > arjun > > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301-212-7860 (M): 240-997-0066 > > > > > "Medhavi Bhatia" > 08/26/2002 11:10 AM > > > To: aroychow@hss.hns.com, "Jiri Kuthan" > cc: "Dean Willis" , > sip@ietf.org, > sip-admin@ietf.org > Subject: Re: [Sip] SIP Traceroute using Max-Forwards > > > > > > > Arjun, > > I was thinking more about the mechanism to do this, and > what others think about the following idea, as a > requirement/implementation: > > If a proxy modifies or adds a header in a request forwarded > by it ( this includes forking), it adds that information (or > the modified header), in a special container header/body of > some sort. I think a simple thing like that may capture a lot > of things for diagnostic purposes. > > -Medhavi. > > ----- Original Message ----- > From: > To: "Jiri Kuthan" > Cc: "Dean Willis" ; > ; > Sent: Monday, August 26, 2002 10:26 AM > Subject: RE: [Sip] SIP Traceroute using Max-Forwards > > > I have just posted a small ID that attempts to capture the > requirements based on our discussion in the list. Its pretty > much in initial stage, but its a start. > > Till it appears on the list, you could find it at (hold your > breath - the link is a mile long ) > > http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhu > ry-sipping-pat > htrace-reqts-00.txt?bcrJka9AQILo3Pai > > Comments welcome. > > One of the questions is whether we need to look at it as > purely a 'diagnostic' requirement or whether we should > generalize it to a 'path information' (which may include > diagnostics, capabilities, > etc) requirement. > > regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301-212-7860 (M): 240-997-0066 > > > > > Jiri Kuthan > Sent by: sip-admin@ietf.org > 08/26/2002 07:47 AM > > > To: "Dean Willis" , > > cc: > Subject: RE: [Sip] SIP Traceroute using Max-Forwards > > > Hi Dean and anyone else looking at this discusssion. > > Thanks to Nils Ohlmeier, there is now beta-version of > *running code* that implements the traceroute functionality. > http://developer.berlios.de/projects/sipsak/ > > It behaves very much like IP traceroute. It sends OPTIONS > requests with increasing Max-Forwards until something else > than 483 or provisional is received. It displays server name > if a downstream server discloses it in Warning header field. > > I too believe there is a need for richer status reporting. > Embedding standardized diagnostic information in SIP replies > would be very useful for network trouble-shooting. If things > go wrong and a negative reply comes back, an upstream client > knows very little now: > - it does not know who generated the reply (the server might be well > hidden in a deep proxy chain and Warnings are optional) > - we do not know which r-uri caused a reply (it might have been > rewritten couple of times) > - we do not know the hop which last relayed our request to > the replying > server (and might be possibly guilty of troubles) > > -Jiri > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > > > DISCLAIMER: This message is proprietary to Hughes Software > Systems Limited (HSS) and is intended solely for the use of > the individual to whom it is addressed. It may contain > privileged or confidential information and should not be > circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please > notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the > contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 27 08:26:06 2002 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 IAA20210 for ; Tue, 27 Aug 2002 08:26:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7RCR6o06079 for sip-archive@odin.ietf.org; Tue, 27 Aug 2002 08:27: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 g7RCOvo05948; Tue, 27 Aug 2002 08:24: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 g7RCKEo05815 for ; Tue, 27 Aug 2002 08:20:14 -0400 Received: from ihemail1.firewall.lucent.com ([192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19670 for ; Tue, 27 Aug 2002 08:18:43 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7RCKAc04565 for ; Tue, 27 Aug 2002 08:20:10 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 14:20:09 +0200 Message-ID: <5160DD6EC1C0D41196D700508B5C167101F7F9C5@it2020exch001u.it.lucent.com> From: "Pianigiani, Jacopo (Jacopo)" To: "'sip@ietf.org'" Subject: [Sip] : The Via header and the "received:" tag: when is this tag filled (and by whom) with the IP address ? Date: Tue, 27 Aug 2002 14:20:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24DC4.140366F2" 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_01C24DC4.140366F2 Content-Type: text/plain; charset="iso-8859-1" Supposing the following typical call flow: atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | a) When is the IP address of each proxy (or UA) added into the VIA header (with the "received:" tag) ? a.1) when the invite is forwarded to the next hop a.2) or when the e.g. 100 Trying response is received backward ? Referring to e.g. message F1 and F3, does Alice's softphone send the INVITE already with its Via header and with the "received:" tag (with Alice's softphone IP addr), or does the Atlanta.com proxy provide the rectified Via header, complemented with Alice's IP address into the Received tag ? I have this confusion since i noticed that in RFC3261 the initial INVITE (page 11) does not have the IP address. Then suddenly, when I see page 14 with the 200 OK messages, all the Via headers are complemented with the "received:" tags with each UA's IP addresses. Thanks in advance and regards Jacopo ------_=_NextPart_001_01C24DC4.140366F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Supposing the following typical call=20 flow:

 

=

      &n= bsp;         =20 atlanta.com  . . . = biloxi.com

           &= nbsp;    =20 .     =20 proxy           &= nbsp; =20 proxy    =20 .

           &= nbsp;  =20 .           &= nbsp;           &= nbsp;          =20     .

      =20 Alice's  . . . . . = . . . . .=20 . . . . . . . . . . =20 Bob's

      = softphone           &= nbsp;           &= nbsp;           &= nbsp;   =20 SIP Phone

        =20 |           &= nbsp;   =20 |           &= nbsp;   =20 |           &= nbsp;   =20 |

        =20 |    = INVITE F1   |           &= nbsp;   =20 |            =     |

        =20 |--------------->|   =20 INVITE F2   = |           &= nbsp;   =20 |

        =20 |  100 Trying F3=20 |--------------->|   =20 INVITE F4  =20 |

        =20 |<---------------|  = 100=20 Trying F5 |--------------->|

        =20 |           &= nbsp;   =20 |<-------------- | 180 Ringing F6=20 |

        =20 |           &= nbsp;   =20 | 180 Ringing F7=20 |<---------------|

        =20 | 180 Ringing F8 |<---------------|     200 OK = F9  = |

        =20 |<---------------| &nbs= p; =20 200 OK F10 =20 |<---------------|

        =20 |    200 = OK=20 F11  = |<---------------|           &= nbsp;   =20 |

        =20 |<---------------|           &= nbsp;   =20 |           &= nbsp;   =20 |

        =20 |           &= nbsp;          =20 ACK F12           &= nbsp;       =20 |

        =20 |------------------------------------------------->|

        =20 |           &= nbsp;      =20 Media Session           &= nbsp;     =20 |

    =20     |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|

        =20 |           &= nbsp;          =20 BYE F13           &= nbsp;       =20 |

        =20 |<-------------------------------------------------|

        =20 |           &= nbsp;        =20 200 OK F14           &= nbsp;      =20 |

        =20 |------------------------------------------------->|

        =20 |           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; =20 |
 
a) When is the IP address of each proxy (or=20 UA) added into the VIA header (with the "received:" tag) ?=20
    a.1) when the invite is = forwarded to=20 the next hop
    a.2) or when the e.g. 100 = Trying=20 response is received backward ?
 
Referring to e.g. message F1 and F3, does = Alice's=20 softphone send the INVITE already with its Via header and with the = "received:"=20 tag (with Alice's softphone  IP addr), or does the Atlanta.com = proxy=20 provide the rectified Via header, complemented with Alice's IP address = into the=20 Received tag ?
I have this confusion since i noticed that = in RFC3261=20 the initial INVITE (page 11) does not have the IP address. Then = suddenly, when I=20 see page 14 with the 200 OK messages, all the Via headers are = complemented with=20 the "received:" tags with each UA's IP addresses.
 
Thanks in advance and = regards
Jacopo
------_=_NextPart_001_01C24DC4.140366F2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 27 10:33:07 2002 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 KAA25608 for ; Tue, 27 Aug 2002 10:33:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7REY9g12456 for sip-archive@odin.ietf.org; Tue, 27 Aug 2002 10:34:09 -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 g7REUKo12257; Tue, 27 Aug 2002 10:30: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 g7REREo12143 for ; Tue, 27 Aug 2002 10:27:15 -0400 Received: from sm6.163.com ([202.108.44.222]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25398 for ; Tue, 27 Aug 2002 10:25:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by sm6.163.com (Postfix) with SMTP id A52E71C704E79 for ; Tue, 27 Aug 2002 22:27:06 +0800 (CST) Received: from danfo (unknown [218.17.231.158]) by 192.168.1.222 (Coremail) with SMTP id uQEAACWMaz2HE+ee.3 for ; Tue, 27 Aug 2002 22:27:06 +0800 (CST) Message-ID: <001901c24dd5$b40cb660$0c01a8c0@huawei.com> From: "wangshan" To: Date: Tue, 27 Aug 2002 22:26:11 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C24E18.BF99BB20" 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] A question about matching rules of response to Client 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C24E18.BF99BB20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sQWxsDQoNCiAgICAgSSBhbSBhIGZyZXNobWFuIG9mIFNJUCwgV2hlbiBJIHJlYWQgdGhl IFJGQzMyNjEsIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZSBzZWN0aW9uICIxNy4xLjMgTWF0 Y2hpbmcgUmVzcG9uc2VzIHRvIENsaWVudCBUcmFuc2FjdGlvbnMiLg0KdGhpcyBzZWN0aW9uIHNh aWQ6DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KICAgICAgICAxLiAgIElmIHRoZSByZXNwb25zZSBoYXMgdGhlIHNhbWUgdmFs dWUgb2YgdGhlIGJyYW5jaCBwYXJhbWV0ZXINCiAgICAgICAgICAgICBpbiB0aGUgdG9wIFZpYSBo ZWFkZXIgZmllbGQgYXMgdGhlIGJyYW5jaCBwYXJhbWV0ZXIgaW4gdGhlDQogICAgICAgICAgICAg dG9wIFZpYSBoZWFkZXIgZmllbGQgb2YgdGhlIHJlcXVlc3QgdGhhdCBjcmVhdGVkIHRoZQ0KICAg ICAgICAgICAgIHRyYW5zYWN0aW9uLg0KDQogICAgICAgIDIuICAgSWYgdGhlIG1ldGhvZCBwYXJh bWV0ZXIgaW4gdGhlIENTZXEgaGVhZGVyIGZpZWxkIG1hdGNoZXMNCiAgICAgICAgICAgICB0aGUg bWV0aG9kIG9mIHRoZSByZXF1ZXN0IHRoYXQgY3JlYXRlZCB0aGUgdHJhbnNhY3Rpb24uIFRoZQ0K ICAgICAgICAgICAgIG1ldGhvZCBpcyBuZWVkZWQgc2luY2UgYSBDQU5DRUwgcmVxdWVzdCBjb25z dGl0dXRlcyBhDQogICAgICAgICAgICAgZGlmZmVyZW50IHRyYW5zYWN0aW9uLCBidXQgc2hhcmVz IHRoZSBzYW1lIHZhbHVlIG9mIHRoZQ0KICAgICAgICAgICAgIGJyYW5jaCBwYXJhbWV0ZXIuDQoN CiAgIEEgcmVzcG9uc2UgdGhhdCBtYXRjaGVzIGEgdHJhbnNhY3Rpb24gbWF0Y2hlZCBieSBhIHBy ZXZpb3VzIHJlc3BvbnNlDQogICBpcyBjb25zaWRlcmVkIGEgcmV0cmFuc21pc3Npb24gb2YgdGhh dCByZXNwb25zZS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KDQpzbyBjb25zaWRlciB0aGUgZm9sbG93aW5nIHNpdHVhdGlvbg0K DQogICAgICAgICAgICAgICAgIFVBICAgICAgICAgICAgICAgICAgICAgIFBST1hZKEZPUkspICAg ICAgICAgVUExICAgICAgICAgVUEyDQoNCiAgICAgICAgICAgICAgICAgICAgICAtLUYxLUlOVklU RS0tLS0+ICAgICAgICAgLS0tRjItSU5WSVRFLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLUYzLS0tLS0tLS0tLUlOVklURS0tLS0+DQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC1GNC0xOFgoVUEx KS0tLS0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC1G NS0tLS0tLS0tLS0tLTE4WChVQTIpLS0tLSANCiAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICA8LUY2LTE4WChVQTEpLS0tLQ0KICAgICAgICAgICAgICAgICAgICAgIDwtRjctMThYKFVB MiktLS0tIA0KICAgICAgDQogICAgVUExIGFuZCBVQTIgYm90aCBzZW5kIDE4eCwgRjQgJiBGNSwg UHJveHkgc2hvdWxkIGZvcndhcmQgYWxsIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGJhY2ssIHNvIEY2 ICYgRjcgYXJlIHRyYW5zbWlzc2lvbiB0byBVQSxidXQgYm90aCBtZXNzYWdlKEY2ICYgRjcpIGhh dmUgdGhlIHNhbWUgVmlhIGhlYWRlciAsc28gaGF2ZSB0aGUgc2FtZSBicmFuY2ggSUQsIGdpdmVu IFVBIHJlY2VpdmVkIEY2IGZpcnN0LGFzIHBlciB0aGUgbWF0Y2hpbmcgcnVsZXMgbWV0aW9uZWQg YWJvdmUsIEY3IHdpbGwgYmUgY29uc2lkZXJlZCBhcyBhIHJldHJhbnNtaXNzaW9uIG9mIEY2LiBJ cyB0aGlzIHNpdHVhdGlvbiByaWdodD8NCiAgICBtb3JlLCBpZiBGNiBpcyB1bnJlbGlhYmxlIHJl c3BvbnNlLCBidXQgRjcgaXMgcmVsaWFibGUgcmVwb25zZSB3aGljaCBuZWVkIGEgUFJBQ0ssIGhv dyB0byBkbz8NCg0KDQogICAgSWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZywgcGxlYXNlIHRl bGwgbWUuIHRoYW5rcyBhaGVhZC4NCg0KDQoNCg== ------=_NextPart_000_0016_01C24E18.BF99BB20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhlbGxvLEFsbDwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYW0gYSBmcmVzaG1hbiBvZiBTSVAs IFdoZW4gSSByZWFkIHRoZSBSRkMzMjYxLCBJIA0KaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZSBz ZWN0aW9uICIxNy4xLjMgTWF0Y2hpbmcgUmVzcG9uc2VzIHRvIENsaWVudCANClRyYW5zYWN0aW9u cyIuPC9ESVY+DQo8RElWPnRoaXMgc2VjdGlvbiBzYWlkOjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCjEuJm5ic3A7Jm5ic3A7IElmIHRoZSByZXNwb25zZSBoYXMgdGhlIHNhbWUgdmFsdWUgb2Yg dGhlIGJyYW5jaCANCnBhcmFtZXRlcjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQppbiB0aGUgdG9wIFZp YSBoZWFkZXIgZmllbGQgYXMgdGhlIGJyYW5jaCBwYXJhbWV0ZXIgaW4gDQp0aGU8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KdG9wIFZpYSBoZWFkZXIgZmllbGQgb2YgdGhlIHJlcXVlc3QgdGhhdCBjcmVh dGVkIA0KdGhlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnRyYW5zYWN0aW9uLjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDIuJm5ic3A7Jm5ic3A7IElmIHRoZSBtZXRob2QgDQpwYXJhbWV0ZXIgaW4gdGhlIENTZXEg aGVhZGVyIGZpZWxkIA0KbWF0Y2hlczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp0aGUgbWV0aG9kIG9m IHRoZSByZXF1ZXN0IHRoYXQgY3JlYXRlZCB0aGUgdHJhbnNhY3Rpb24uIA0KVGhlPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCm1ldGhvZCBpcyBuZWVkZWQgc2luY2UgYSBDQU5DRUwgcmVxdWVzdCBjb25z dGl0dXRlcyANCmE8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZGlmZmVyZW50IHRyYW5zYWN0aW9uLCBi dXQgc2hhcmVzIHRoZSBzYW1lIHZhbHVlIG9mIA0KdGhlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmJy YW5jaCBwYXJhbWV0ZXIuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJz cDsgQSByZXNwb25zZSB0aGF0IG1hdGNoZXMgYSB0cmFuc2FjdGlvbiBtYXRjaGVkIGJ5IGEgcHJl dmlvdXMgDQpyZXNwb25zZTxCUj4mbmJzcDsmbmJzcDsgaXMgY29uc2lkZXJlZCBhIHJldHJhbnNt aXNzaW9uIG9mIHRoYXQgDQpyZXNwb25zZS48QlI+KioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPjwvRElWPg0KPERJVj5zbyBjb25z aWRlciB0aGUgZm9sbG93aW5nIHNpdHVhdGlvbjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KVUEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpQUk9YWShGT1JLKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANClVBMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBVQTI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0t RjEtSU5WSVRFLS0tLSZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDstLS1GMi1JTlZJVEUtLSZndDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0tRjMtLS0tLS0tLS0t SU5WSVRFLS0tLSZndDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZsdDstRjQtMThYKFVBMSkt LS0tPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZsdDstRjUtLS0tLS0tLS0tLS0xOFgoVUEyKS0tLS0mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvRElWPg0KPERJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJmx0Oy1GNi0xOFgoVUExKS0t LS08L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJmx0Oy1GNy0xOFgoVUEyKS0tLS0mbmJzcDs8 L0RJVj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9E SVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBVQTEgYW5kIFVBMiBib3RoIHNlbmQgMTh4LCBG NCAmYW1wOyBGNSwgUHJveHkgc2hvdWxkIA0KZm9yd2FyZCBhbGwgcHJvdmlzaW9uYWwgcmVzcG9u c2UgYmFjaywgc28gRjYgJmFtcDsgRjcgYXJlIHRyYW5zbWlzc2lvbiB0byBVQSxidXQgDQpib3Ro IG1lc3NhZ2UoRjYgJmFtcDsgRjcpIGhhdmUgdGhlIHNhbWUgVmlhIGhlYWRlciAsc28gaGF2ZSB0 aGUgc2FtZSBicmFuY2ggSUQsIA0KZ2l2ZW4gVUEgcmVjZWl2ZWQgRjYgZmlyc3QsYXMgcGVyIHRo ZSBtYXRjaGluZyBydWxlcyBtZXRpb25lZCBhYm92ZSwgRjcgd2lsbCBiZSANCmNvbnNpZGVyZWQg YXMgYSByZXRyYW5zbWlzc2lvbiBvZiBGNi4gSXMgdGhpcyBzaXR1YXRpb24gcmlnaHQ/PC9ESVY+ DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBtb3JlLCBpZiBGNiBpcyB1bnJlbGlhYmxlIHJlc3Bv bnNlLCBidXQgRjcgaXMgcmVsaWFibGUgDQpyZXBvbnNlIHdoaWNoIG5lZWQgYSBQUkFDSywgaG93 IHRvIGRvPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOyZuYnNwOyZuYnNwOyBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLCBwbGVhc2Ug dGVsbCBtZS4gdGhhbmtzIA0KYWhlYWQuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0016_01C24E18.BF99BB20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 27 10:45:08 2002 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 KAA26130 for ; Tue, 27 Aug 2002 10:45:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7REkAt13411 for sip-archive@odin.ietf.org; Tue, 27 Aug 2002 10:46:10 -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 g7REeLo13215; Tue, 27 Aug 2002 10:40: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 g7REdQo13139 for ; Tue, 27 Aug 2002 10:39:26 -0400 Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25855 for ; Tue, 27 Aug 2002 10:37:52 -0400 (EDT) Message-Id: <200208271437.KAA25855@ietf.org> Received: (qmail 6372 invoked from network); 27 Aug 2002 14:56:07 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 27 Aug 2002 14:56:07 -0000 Date: Tue, 27 Aug 2002 22:47:21 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "Pianigiani, Jacopo (Jacopo)" , "sip@ietf.org" Subject: Re: [Sip] : The Via header and the "received:" tag: when is this tagfilled (and by whom) with the IP address ? Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g7REdQo13140 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 Jacopo, I think the process likes this: 1) Atlanta.com proxy receives Alice's INVITE from Alice's IP, and the proxy can see the IP; 2) The proxy adds "received" tag in the Via header; 3) The proxy then adds it's own SIP URI in the topmost of Via header; 4) The proxy sends the INVITE to Bob's proxy; Best Regards. > Supposing the following typical call flow: > > > > atlanta.com . . . biloxi.com > > . proxy proxy . > > . . > > Alice's . . . . . . . . . . . . . . . . . . . . Bob's > > softphone SIP Phone > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > | 100 Trying F3 |--------------->| INVITE F4 | > > |<---------------| 100 Trying F5 |--------------->| > > | |<-------------- | 180 Ringing F6 | > > | | 180 Ringing F7 |<---------------| > > | 180 Ringing F8 |<---------------| 200 OK F9 | > > |<---------------| 200 OK F10 |<---------------| > > | 200 OK F11 |<---------------| | > > |<---------------| | | > > | ACK F12 | > > |------------------------------------------------->| > > | Media Session | > > |<================================================>| > > | BYE F13 | > > |<-------------------------------------------------| > > | 200 OK F14 | > > |------------------------------------------------->| > > | | > >a) When is the IP address of each proxy (or UA) added into the VIA header (with the "received:" tag) ? > a.1) when the invite is forwarded to the next hop > a.2) or when the e.g. 100 Trying response is received backward ? > >Referring to e.g. message F1 and F3, does Alice's softphone send the INVITE already with its Via header and with the "received:" tag (with Alice's softphone IP addr), or does the Atlanta.com proxy provide the rectified Via header, complemented with Alice's IP address into the Received tag ? >I have this confusion since i noticed that in RFC3261 the initial INVITE (page 11) does not have the IP address. Then suddenly, when I see page 14 with the 200 OK messages, all the Via headers are complemented with the "received:" tags with each UA's IP addresses. > >Thanks in advance and regards >Jacopo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 27 15:42:06 2002 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 PAA09268 for ; Tue, 27 Aug 2002 15:42:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7RJhA330256 for sip-archive@odin.ietf.org; Tue, 27 Aug 2002 15:43:10 -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 g7RJgjo30232; Tue, 27 Aug 2002 15:42: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 g7RJGho28224 for ; Tue, 27 Aug 2002 15:16:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [Sip] Nomcom call for volunteers 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 members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 28 06:30:53 2002 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 GAA22746 for ; Wed, 28 Aug 2002 06:30:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SAVqn18671 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 06:31:52 -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 g7SATAo18554; Wed, 28 Aug 2002 06:29:10 -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 g7SARko18508 for ; Wed, 28 Aug 2002 06:27:46 -0400 Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22658 for ; Wed, 28 Aug 2002 06:26:15 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g7SARCi27527 for ; Wed, 28 Aug 2002 15:57:12 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H1JUD600.8HY for ; Wed, 28 Aug 2002 15:57:06 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 15:57:06 +0530 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.5762.3 Date: Wed, 28 Aug 2002 15:57:05 +0530 Message-ID: <860BFD79D602F0409BB9EEA42B9E3BC02793D7@blr-m1-msg.wipro.com> Thread-Topic: Refer subscription duration Thread-Index: AcJOfXPg4z3c+q8tTDmXy9WrJxOvSw== From: "Reshmi Nair" To: X-OriginalArrivalTime: 28 Aug 2002 10:27:06.0221 (UTC) FILETIME=[751871D0:01C24E7D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7SARko18509 Subject: [Sip] Refer subscription duration 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, The " draft-ietf-sip-refer-06.txt " says that the duration of the subscription is determined by the expires parameter in the Subscription State header of the first Notify. [Section 3.4]. Does that mean the the first Notify 'MUST' have an expires parameter in the Subscription State header ?? If not, what should be the duration of the refer-subscription ? There is no default value suggested. Regards, Reshmi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 28 07:18:31 2002 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 HAA23743 for ; Wed, 28 Aug 2002 07:18:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SBJVK21213 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 07:19: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 g7SBIoo21203; Wed, 28 Aug 2002 07:18: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 g7SBHjo21161 for ; Wed, 28 Aug 2002 07:17:45 -0400 Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23717 for ; Wed, 28 Aug 2002 07:16:14 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA11607; Wed, 28 Aug 2002 13:17:35 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA29593; Wed, 28 Aug 2002 13:17:34 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 13:17:21 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74EDF@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Reshmi Nair'" , sip@ietf.org Cc: "'adam@dynamicsoft.com'" Subject: RE: [Sip] Refer subscription duration Date: Wed, 28 Aug 2002 13:15:46 +0200 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: , Hi Reshmi, This was discussed before. Please read : http://www1.ietf.org/mail-archive/working-groups/sip/current/msg05612.html Regards, Ya-Ching | -----Original Message----- | From: Reshmi Nair [mailto:reshmi.nair@wipro.com] | Sent: 28 August 2002 12:27 | To: sip@ietf.org | Subject: [Sip] Refer subscription duration | | | Hi, | | The " draft-ietf-sip-refer-06.txt " says that the duration of | the subscription is determined by the expires parameter in | the Subscription State header of the first Notify. [Section 3.4]. | | Does that mean the the first Notify 'MUST' have an expires | parameter in the Subscription State header ?? | | If not, what should be the duration of the refer-subscription | ? There is no default value suggested. | | | Regards, | Reshmi | | | _______________________________________________ | Sip mailing list https://www1.ietf.org/mailman/listinfo/sip | This list is for NEW development of the core SIP Protocol | Use sip-implementors@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 Aug 28 07:46:07 2002 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 HAA24234 for ; Wed, 28 Aug 2002 07:46:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SBl7i22610 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 07:47: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 g7SBkco22593; Wed, 28 Aug 2002 07:46: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 g7SBhWo22462 for ; Wed, 28 Aug 2002 07:43:32 -0400 Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24189 for ; Wed, 28 Aug 2002 07:41:56 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17k1I1-0003AD-00; Wed, 28 Aug 2002 17:17:13 +0530 Message-ID: <001801c24e88$2660ebc0$5f0d0a0a@ranjit> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: "Reshmi Nair" , References: <860BFD79D602F0409BB9EEA42B9E3BC02793D7@blr-m1-msg.wipro.com> Subject: Re: [Sip] Refer subscription duration Date: Wed, 28 Aug 2002 17:13:38 +0530 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Reshmi In case u don't specify the duration of ur subsciption in the Expires header of SUBSCRIBE, then server sets the value of the subscription to some default valu which is conveyed in the Expires header of NOTIFY. Subscription-State header conveys the state of the subscription Viz: "init" , "active" or "terminated" Ranjit ----- Original Message ----- From: Reshmi Nair To: Sent: Wednesday, August 28, 2002 3:57 PM Subject: [Sip] Refer subscription duration > Hi, > > The " draft-ietf-sip-refer-06.txt " says that the duration of the subscription is determined by the expires parameter in the Subscription State header of the first Notify. [Section 3.4]. > > Does that mean the the first Notify 'MUST' have an expires parameter in the Subscription State header ?? > > If not, what should be the duration of the refer-subscription ? There is no default value suggested. > > > Regards, > Reshmi > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 28 08:07:45 2002 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 IAA25945 for ; Wed, 28 Aug 2002 08:07:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SC8k224074 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 08:08: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 g7SC8Mo24043; Wed, 28 Aug 2002 08:08: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 g7SBxoo23019 for ; Wed, 28 Aug 2002 07:59:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25220; Wed, 28 Aug 2002 07:58:17 -0400 (EDT) Message-Id: <200208281158.HAA25220@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: Wed, 28 Aug 2002 07:58:17 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-asserted-identity-02.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 : Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks Author(s) : C. Jennings, J. Peterson, M. Watson Filename : draft-ietf-sip-asserted-identity-02.txt Pages : 18 Date : 2002-8-27 This document describes private extensions to SIP that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-02.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-asserted-identity-02.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-asserted-identity-02.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: <2002-8-27144948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-asserted-identity-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-asserted-identity-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144948.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 Wed Aug 28 08:07:49 2002 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 IAA25963 for ; Wed, 28 Aug 2002 08:07:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SC8mw24087 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 08:08: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 g7SC8To24065; Wed, 28 Aug 2002 08:08: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 g7SBxso23024 for ; Wed, 28 Aug 2002 07:59:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25243; Wed, 28 Aug 2002 07:58:22 -0400 (EDT) Message-Id: <200208281158.HAA25243@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: Wed, 28 Aug 2002 07:58:21 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-scvrtdisco-01.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 for Service Route Discovery During Registration Author(s) : D. Willis, B. Hoeneisen Filename : draft-ietf-sip-scvrtdisco-01.txt Pages : 15 Date : 2002-8-27 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-01.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-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-scvrtdisco-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-27144959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-scvrtdisco-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-scvrtdisco-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144959.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 Wed Aug 28 09:03:45 2002 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 JAA28195 for ; Wed, 28 Aug 2002 09:03:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SD4kP27013 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 09: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 g7SD4Eo26983; Wed, 28 Aug 2002 09:04: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 g7SD0Do26754 for ; Wed, 28 Aug 2002 09:00:13 -0400 Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28000 for ; Wed, 28 Aug 2002 08:58:39 -0400 (EDT) Message-Id: <200208281258.IAA28000@ietf.org> Received: (qmail 29512 invoked from network); 28 Aug 2002 13:17:01 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 28 Aug 2002 13:17:01 -0000 Date: Wed, 28 Aug 2002 21:8:17 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g7SD0Do26755 Subject: [Sip] What's the Changes? 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, Who can tell me the CHANGES between draft-ietf-sip-scvrtdisco-00 and draft-ietf-sip-scvrtdisco-01 ? Thanks a lot! Best Regards. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 28 16:21:39 2002 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 QAA17098 for ; Wed, 28 Aug 2002 16:21:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SKMid19550 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 16:22: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 g7SKKso19501; Wed, 28 Aug 2002 16:20:54 -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 g7SKIwo19404 for ; Wed, 28 Aug 2002 16:18:58 -0400 Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17000 for ; Wed, 28 Aug 2002 16:17:21 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g7SKIL309886; Wed, 28 Aug 2002 15:18:21 -0500 From: "Dean Willis" To: , Subject: RE: [Sip] What's the Changes? Date: Wed, 28 Aug 2002 15:18:12 -0500 Message-ID: <00cb01c24ed0$0c65d6c0$a6036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200208281258.IAA28000@ietf.org> 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 Fixed two errors in the abnf that had been left over from ripping out the p- stuff. Clarified discussion of the relevance of sip-change process in the IANA considerations section. Cleaned up some of the wording around Alternatve 3 to say that the referenced inbound routing technique with look-up tables is used in some 3G networks. In other words, it is very likely that you will notice any change at all unless you were one of the people who specifically requested a change. -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of feng zhang > Sent: Wednesday, August 28, 2002 8:00 AM > To: sip@ietf.org > Subject: [Sip] What's the Changes? > > > Hi All, > > Who can tell me the CHANGES between > draft-ietf-sip-scvrtdisco-00 and draft-ietf-sip-scvrtdisco-01 ? > > Thanks a lot! > > Best Regards. > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 28 21:49:45 2002 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 VAA27298 for ; Wed, 28 Aug 2002 21:49:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7T1oqh04252 for sip-archive@odin.ietf.org; Wed, 28 Aug 2002 21:50:52 -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 g7T1oVo04224; Wed, 28 Aug 2002 21:50: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 g7T1nRo04184 for ; Wed, 28 Aug 2002 21:49:27 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27233 for ; Wed, 28 Aug 2002 21:47:49 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g7T1mnds004841; Wed, 28 Aug 2002 18:48:49 -0700 (PDT) Received: from open-131-161-248-81.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAT76019; Wed, 28 Aug 2002 18:47:07 -0700 (PDT) Date: Wed, 28 Aug 2002 18:49:19 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: mankin@psg.com, fluffy@cisco.com, jon.peterson@neustar.biz, Mark Watson , rohan@cisco.com To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <88CD607D-BAF1-11D6-BC81-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Subject: [Sip] asserted-identity-02 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 Folks, As someone pointed out in Yokohama, the asserted-identity-01 draft that was in the archives then did not reflect WG consensus on the matter of separate header vs. same header for the hint. (This was due to a coordination SNAFU as the draft went to IESG review.) The -02 version of asserted identity that just appeared in the archive corrected this inconsistency. 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 Thu Aug 29 03:16:43 2002 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 DAA12393 for ; Thu, 29 Aug 2002 03:16:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7T7Hr127002 for sip-archive@odin.ietf.org; Thu, 29 Aug 2002 03:17: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 g7T7CPo26851; Thu, 29 Aug 2002 03:12: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 g7T7AVo26810 for ; Thu, 29 Aug 2002 03:10:31 -0400 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12280 for ; Thu, 29 Aug 2002 03:08:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7T7AIV05674 for ; Thu, 29 Aug 2002 10:10:18 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 29 Aug 2002 10:10:15 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Aug 2002 10:10:15 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Aug 2002 10:10:14 +0300 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: Thu, 29 Aug 2002 10:10:14 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20548@esebe019.ntc.nokia.com> Thread-Topic: Record-route uri must be sip or sips Thread-Index: AcJPKx8YHLERgz7MQPCKuwUHtcMUeg== To: X-OriginalArrivalTime: 29 Aug 2002 07:10:15.0044 (UTC) FILETIME=[1F7F9C40:01C24F2B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7T7AVo26811 Subject: [Sip] Record-route uri must be sip or sips 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 16.6 item 4 states that "The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI" But the grammar for record-route allows absolute URI. Why allow it in the grammar? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Aug 29 06:29:34 2002 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 GAA14856 for ; Thu, 29 Aug 2002 06:29:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TAUZl03777 for sip-archive@odin.ietf.org; Thu, 29 Aug 2002 06:30: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 g7TARqo03680; Thu, 29 Aug 2002 06:27: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 g7TAOSo03587 for ; Thu, 29 Aug 2002 06:24:28 -0400 Received: from ndc.vsnl.net.in (del3.vsnl.net.in [202.54.96.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14757 for ; Thu, 29 Aug 2002 06:22:55 -0400 (EDT) Received: from t (localhost [127.0.0.1]) by ndc.vsnl.net.in (Postfix) with SMTP id 1502843954 for ; Thu, 29 Aug 2002 10:23:13 +0000 (IST) Received: from ([203.197.201.36]) by delcluster1.vsnl.net.in (InterScan E-Mail VirusWall Unix); Thu, 29 Aug 2002 15:53:21 +0530 (IST) Message-ID: <001401c24f47$6e654c80$24c9c5cb@t> From: "Tirthankar Saha" To: "SIP Mailing List" Date: Thu, 29 Aug 2002 15:58:09 +0530 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] Session Timer Issues and Proposal 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 folks, I feel there are some issues with the Sip Session Timer spec and that it can be made simpler and more useful. I'm submitting a rough proposal for improving the spec and would appreciate your comments. I haven't followed any previous discussions on this issue on the mailing list, so I might be missing something. I thought that the shortcomings would be addressed in a later version of the draft but it hasn't happened. So before this draft attains RFC status like all the other ones, it's better that we have another discussion on this topic. Regards, Tirthankar -------------------------------------------------------------- Issues: 1) Why do we have to refresh the session with a re-INVITE? Lots of unnecessary processing for a simple keepalive. - 3 way handshake - sdp re-negotiation & possible re-opening of media channels This could have been justified earlier when the refresh-intervals were recommended to be 30 mins. but this feature is now being considered to be used for keeping the NAT bindings alive. This means that the refresh-intervals are going to be as low as 30secs. I think using the re-INVITE to refresh a dialog is seriously flawed; I can't think of any good reason for having this procedure. We MUST address this issue ASAP. 2) Unnecessary processing & complications with "refresher" param. What do we gain by negotiating who's going to be the referesher? On the other hand, extra work is required which can be avoided by having a simple rule for deciding the refresher (ref. proposal below). This way we can avoid the min-timer checks for DoS attacks and reduce interoperability issues arising out of certain non-conforming vendor implementations which don't use this param at all. 3) Unnecessary confusion with call-hold. There's no way to tell whether incoming re-INVITE is for session-refresh or session-modification. e.g A & B in call & A is the refresher. Now, B holds the call and A is still the refresher due to a specific case of negotiation of refresher param. If, A sends the refresh then B can't determine whether A is trying to modify the session or refresh the session. B would reject the request (because he's holding the call & won't allow A to unhold himself) & A MIGHT terminate the call. 4) No uniform strategy for dialog keep-alive : separate procedures for INVITE,REGISTER & SUBSCRIBE/NOTIFY dialogs. PROPOSAL ======== Common dialog-keepalive strategy though I've considered only INVITE dialogs. Can be extended easily for other dialogs (I feel). New feature tag (for use in Supported,Require headers): dtimer New Header Dialog-Expires: - Can be included in ANY request and/or its response except BYE or other requests terminating the dialog. - It MUST be included in the dialog-refresh request which can be any valid request in the dialog although the INFO request is recommended. - It is recommended that the UA intiating the dialog SHOULD send this header in the initial INVITE. - If the request doesn't contain this header, the UAS can add it in the response ONLY if the Supported header of request contains the feature-tag "dtimer". - The endpoint (uac/uas) MUST include a supported header in the message containing this header with the feature-tag "dtimer". - Proxies MUST NOT CHANGE this header. - Logic for determining the refresher: if (message contains "Supported: dtimer") AND ("Dialog-Expires" hdr present in the message) { if (message is REQUEST) { uac becomes the refresher } else { uas becomes the refresher } } else { feature disabled } ie. whoever sends this hdr in a transaction first becomes the refresher. - Logic for (re)starting expiry timer: if (incoming-message contains "Dialog-Expires" header) AND (message contains Supported header with the feature-tag "dtimer") - refresher role CANNOT be renegotiated. QUERY: Is this OK? Would renegotiation be needed in any case? If yes, does it justify the extra renegotiation logic reqd.? - refresh & expiry time calculations are the same as in the session-timer draft. SCENARIOS ========= NOTE: INVITE dialog is assumed. Endpoint A : Dialog initiator/Calling party/Initial UAC Endpoint B : Called party/Initial UAS Intermediate server S: proxy/B2BUA. 1) Feature supported by BOTH endpoints. A includes "Dialog-Expires" header & "dtimer" in "Supported" header in the initial INVITE request. B echoes the header in the response and includes "dtimer" in the Supported header of the response. As a result, A becomes the refresher. It sends the refresh in INFO request which includes the "Dialog-Expires" header, as a result of which B restarts the timer. 1.1) Refresh A sends INFO request with "Dialog-Expires" header. B restarts the expiry timer. 1.2) B goes down A sends refresh and receives no response. After timeout A sends BYE. 1.3) B goes down & comes up again A sends refresh and receives 481 response. A sends BYE. 1.4) A goes down B doesn't recv refreshes & sends BYE. 1.5) A holds the call and includes "Dialog-Expires" in the re-INVITE to avoid sending extra message for refreshing the dialog. B restarts the expiry timer upon receiving the re-INVITE. 1.6) On-the-wire: A & B send re-INVITE "simultaneously" There would be a race condition if renegotiation was allowed and both endpoints included the "Dialog-Expires" header in the re-INVITEs. Since renegotiation is not allowed, A would continue to be the refresher. 2) Feature supported ONLY by A & S B doesn't send "Supported: dtimer" in response but S inserts it and A starts the refresh timer. 3) Feature supported ONLY by B & S S inserts "Supported: dtimer" in the request and B inserts the "Dialog-Expires" header & becomes the refresher. S removes the "Dialog-Expires" header when forwarding the response to A. 4) Feature supported ONLY by A A doesn't recv "Supported: dtimer" in the response as neither B nor S supports the feature and hence disables the feature. 5) Feature supported ONLY by B B doesn't recv "Supported: dtimer" in the request as neither A nor S supports the feature and hence disables the feature. 6) No endpt. support Feature is disabled. However, S can "query" the dialog-status by sending an INFO request to all the endpoints in the dialog. It CAN release its resources if any of the INFO requests elicit a 481 response or no answer. This method can also be used by the UAs as an extra safety-check although it is not recommended. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 29 10:23:37 2002 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 KAA23601 for ; Thu, 29 Aug 2002 10:23:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TEOdj16840 for sip-archive@odin.ietf.org; Thu, 29 Aug 2002 10:24: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 g7TENRo16817; Thu, 29 Aug 2002 10:23: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 g7TEKHo16678 for ; Thu, 29 Aug 2002 10:20:17 -0400 Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23363 for ; Thu, 29 Aug 2002 10:18:44 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g7T8UD107588; Thu, 29 Aug 2002 03:30:14 -0500 Subject: Re: [Sip] Record-route uri must be sip or sips From: Robert Sparks To: hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C20548@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7C20548@esebe019.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 29 Aug 2002 09:14:41 -0500 Message-Id: <1030630482.1830.17.camel@dhcp174.dfw.dynamicsoft.com> Mime-Version: 1.0 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 We have lots of places where the grammar allows you to produce a message that isn't semantically valid. Both the text and the grammar have to be taken together. For example, the Contact header field takes an arbitrary number of name-addrs. But all the currently defined methods other than REGISTER restrict it to containing exactly one SIP or SIPS URI. We've developed a convention of expressing the grammar for header field parameters that allow arbitrary numbers of each parameters in each field value - the text almost always adds a "zero or one" restriction. Every time we've discussed attempting to push all these restrictions into the grammar, we end up deciding that the "grammar plus tuning text" approach makes the specification easier for humans to understand. RjS On Thu, 2002-08-29 at 02:10, hisham.khartabil@nokia.com wrote: > Section 16.6 item 4 states that > > "The URI placed in the Record-Route header field value MUST be a > SIP or SIPS URI" > > But the grammar for record-route allows absolute URI. Why allow it in the grammar? > > Regards, > Hisham > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 29 18:21:12 2002 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 SAA13472 for ; Thu, 29 Aug 2002 18:21:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TMMI510132 for sip-archive@odin.ietf.org; Thu, 29 Aug 2002 18:22: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 g7TML8o10072; Thu, 29 Aug 2002 18:21: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 g7TMJmo10003 for ; Thu, 29 Aug 2002 18:19:48 -0400 Received: from tnint11.telogy.design.ti.com ([209.116.120.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13384 for ; Thu, 29 Aug 2002 18:18:11 -0400 (EDT) Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 18:19:09 -0400 Message-ID: <37A3C2F21006D611995100B0D0F9B73C028BEE@tnint11.telogy.design.ti.com> From: "Yadavalli, Satyamurthy" To: "'sip@ietf.org'" Date: Thu, 29 Aug 2002 18:19:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24FAA.17B88B00" Subject: [Sip] Sip Gateway Controller 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_01C24FAA.17B88B00 Content-Type: text/plain; charset="iso-8859-1" Is there any effort at IETF to use SIP in a call agent model (instead of the peer-peer model that SIP is popular as) where the endpoints are not 'intelligent' and instead are controlled by a central controller - as in the case of MGCP/Megaco - to which all events (e.g., telephony events) are reported to and the callAgent/controller instructs the endpoint to setup media sessions or play signals etc., This has similarity with the primarily peer-peer H323 model extended to behave "megaco like" using the H323-Annex-M specification. Is the SIP's "third party call control (3pcc)" effort anything towards this direction? -Satya ------_=_NextPart_001_01C24FAA.17B88B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there=20 any effort at IETF to use SIP in a call agent model (instead of = the=20 peer-peer model that SIP is popular as) where the endpoints are not=20 'intelligent' and instead are controlled by a central controller = - as in=20 the case of MGCP/Megaco - to which all events (e.g., telephony events) = are=20 reported to and the callAgent/controller instructs the endpoint to = setup media=20 sessions or play signals etc.,
 
This has=20 similarity with the primarily peer-peer H323 model extended to behave = "megaco=20 like" using the H323-Annex-M specification.=20
 
Is the=20 SIP's "third party call control (3pcc)" effort anything towards this = direction?=20
 
-Satya
 
 
 
 
 
 
 
 
 
------_=_NextPart_001_01C24FAA.17B88B00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 29 19:24:40 2002 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 TAA15048 for ; Thu, 29 Aug 2002 19:24:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TNPlu12911 for sip-archive@odin.ietf.org; Thu, 29 Aug 2002 19:25: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 g7TNOto12885; Thu, 29 Aug 2002 19:24: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 g7TNN7o12843 for ; Thu, 29 Aug 2002 19:23:07 -0400 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14999 for ; Thu, 29 Aug 2002 19:21:28 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7TNMawc006447 for ; Thu, 29 Aug 2002 19:22:36 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ00184; Thu, 29 Aug 2002 19:27:12 -0400 (EDT) Message-ID: <3D6EACB3.CC2C8F04@cisco.com> Date: Thu, 29 Aug 2002 19:22:27 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: RFC 3264 An Offer/Answer Model Session Description Protocol 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 question of interpretation regarding section 8.3.2 (Changing the Set of Media Formats). When describing how an offer is to be constructed for a change (a reINVITE), this section says: "However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session." What I question is the "or answers" at the end of this section. This seems to be inconsistent with section 6.1, which says that the payload type numbers for answers may be different than those for offers. These aren't necessarily inconsistent if another constraint is added to 6.1, saying that when the answer changes the payload number from what was in the offer, it must be a number that doesn't already have an association with a particular payload type in the current session. But I don't think that is what was intended. (My impression is that the intent is to permit the two sides to have totally independent numberings for codecs.) The alternative interpretation is that section 8.3.2 is a bit overzealous, and that the mapping between payload type numbers and codecs only needs to be consistent for a particular endpoint of a session. This is probably not a big deal, because the suggestion that this applies to both directions rather than each direction independently only appears in an example. I realize it would have been better to ask about this before or during last call. But I just didn't get around to it. Sorry! Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Aug 30 03:57:13 2002 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 DAA06632 for ; Fri, 30 Aug 2002 03:57:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7U7wOo14213 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 03:58: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 g7U7vJo14123; Fri, 30 Aug 2002 03:57: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 g7U7tFo14039 for ; Fri, 30 Aug 2002 03:55:15 -0400 Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06512 for ; Fri, 30 Aug 2002 03:53:33 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g7U7sVi00348 for ; Fri, 30 Aug 2002 13:24:31 +0530 (IST) Received: from blr-m1-bh2.wipro.com ([10.115.50.92]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H1NCMP00.7C5 for ; Fri, 30 Aug 2002 13:24:25 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 13:24:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Aug 2002 13:24:25 +0530 Message-ID: <860BFD79D602F0409BB9EEA42B9E3BC027970B@blr-m1-msg.wipro.com> Thread-Topic: [Sip] Refer subscription duration Thread-Index: AcJOiGjLzxhGwy9nQbC/YFrWgzj5qgBcMkYw From: "Reshmi Nair" To: X-OriginalArrivalTime: 30 Aug 2002 07:54:25.0693 (UTC) FILETIME=[75D24CD0:01C24FFA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7U7tFo14040 Subject: [Sip] Refer Final Response 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, Quoting from RFC 3265 - SIP - Specific Event Notification, section 3.1.4.1 : " A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted. " Is this true for a refer subscription too ? Are we expected to send a 200 OK for Refer, if authorization is successful before the transaction times out ? All the call flows for refer only show a "202 Accepted" being sent as a response to refer. That makes me wonder. Please let me know. Regards, Reshmi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 30 05:07:50 2002 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 FAA08325 for ; Fri, 30 Aug 2002 05:07:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7U98oE18822 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 05:08: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 g7U97eo18787; Fri, 30 Aug 2002 05:07: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 g7U965o18166 for ; Fri, 30 Aug 2002 05:06:05 -0400 Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08242 for ; Fri, 30 Aug 2002 05:04:32 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17khmV-0001hj-00; Fri, 30 Aug 2002 14:39:31 +0530 Message-ID: <001801c25004$7136c020$5f0d0a0a@ranjit> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: "Reshmi Nair" , References: <860BFD79D602F0409BB9EEA42B9E3BC027970B@blr-m1-msg.wipro.com> Subject: Re: [Sip] Refer Final Response Date: Fri, 30 Aug 2002 14:35:52 +0530 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 reshmi In case of call transfer, first u send 202 Accepted for REFER and u send a NOTIFY confirming that REFER was successful. Ranjit ----- Original Message ----- From: Reshmi Nair To: Sent: Friday, August 30, 2002 1:24 PM Subject: [Sip] Refer Final Response > Hi, > > Quoting from RFC 3265 - SIP - Specific Event Notification, section 3.1.4.1 : > > " A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted. " > > Is this true for a refer subscription too ? Are we expected to send a 200 OK for Refer, if authorization is successful before the transaction times out ? > All the call flows for refer only show a "202 Accepted" being sent as a response to refer. That makes me wonder. > > Please let me know. > > Regards, > Reshmi > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 30 05:10:38 2002 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 FAA08434 for ; Fri, 30 Aug 2002 05:10:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7U9BcP18932 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 05:11: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 g7U9B9o18900; Fri, 30 Aug 2002 05:11: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 g7U9Aoo18870 for ; Fri, 30 Aug 2002 05:10:50 -0400 Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08383 for ; Fri, 30 Aug 2002 05:09:17 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g7U9AGi12771 for ; Fri, 30 Aug 2002 14:40:16 +0530 (IST) Received: from blr-m1-bh2.wipro.com ([10.115.50.92]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H1NG4Y01.PDQ; Fri, 30 Aug 2002 14:40:10 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 14:40:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Refer Final Response Date: Fri, 30 Aug 2002 14:40:09 +0530 Message-ID: <860BFD79D602F0409BB9EEA42B9E3BC0279740@blr-m1-msg.wipro.com> Thread-Topic: [Sip] Refer Final Response Thread-Index: AcJQBF4/SlLh6hXdT2CZADy9yAvd7AAADBTA From: "Reshmi Nair" To: "Ranjit Avasarala" , X-OriginalArrivalTime: 30 Aug 2002 09:10:10.0300 (UTC) FILETIME=[0A9E4BC0:01C25005] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7U9Aoo18871 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, Does that mean that : " A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted. " - as in the Sip Event RFC is not true for Refer ?? Reshmi -----Original Message----- From: Ranjit Avasarala [mailto:ranjit.avasarala@bplmail.com] Sent: Friday, August 30, 2002 2:36 PM To: Reshmi Nair; sip@ietf.org Subject: Re: [Sip] Refer Final Response Hi reshmi In case of call transfer, first u send 202 Accepted for REFER and u send a NOTIFY confirming that REFER was successful. Ranjit ----- Original Message ----- From: Reshmi Nair To: Sent: Friday, August 30, 2002 1:24 PM Subject: [Sip] Refer Final Response > Hi, > > Quoting from RFC 3265 - SIP - Specific Event Notification, section 3.1.4.1 : > > " A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted. " > > Is this true for a refer subscription too ? Are we expected to send a 200 OK for Refer, if authorization is successful before the transaction times out ? > All the call flows for refer only show a "202 Accepted" being sent as a response to refer. That makes me wonder. > > Please let me know. > > Regards, > Reshmi > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 30 06:27:30 2002 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 GAA10082 for ; Fri, 30 Aug 2002 06:27:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UASWx22571 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 06:28:32 -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 g7UAQvo22529; Fri, 30 Aug 2002 06:26: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 g7UAPLo22475 for ; Fri, 30 Aug 2002 06:25:21 -0400 Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10022 for ; Fri, 30 Aug 2002 06:23:48 -0400 (EDT) From: RANJIT.AVASARALA@bplmail.com Received: from btlmail.bplmail.com ([127.0.0.1] helo=bplmail.com) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17kiPc-0002MD-00; Fri, 30 Aug 2002 15:19:56 +0530 Received: from 10.10.13.93 (SquirrelMail authenticated user RANJIT.AVASARALA) by btlmail.bplmail.com with HTTP; Fri, 30 Aug 2002 15:19:56 +0530 (IST) Message-ID: <1292.10.10.13.93.1030700996.squirrel@btlmail.bplmail.com> Date: Fri, 30 Aug 2002 15:19:56 +0530 (IST) To: reshmi.nair@wipro.com In-Reply-To: <860BFD79D602F0409BB9EEA42B9E3BC0279740@blr-m1-msg.wipro.com> References: <860BFD79D602F0409BB9EEA42B9E3BC0279740@blr-m1-msg.wipro.com> Cc: ranjit.avasarala@bplmail.com, sip@ietf.org X-Mailer: SquirrelMail (version 1.0.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] =?iso-8859-1?Q?RE:_[Sip]_Refer_Final_Response?= 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 subscription is accepted u get a NOTIFY indicating the subscription- state as "active" and duration of subscription in Expires: header. Ranjit > Hi, > > Does that mean that : > " A 200 response indicates that the subscription has been accepted and > that the user is authorized to subscribe to the requested resource. A > 202 response merely indicates that the subscription has been > understood, and that authorization may or may not have been granted. " > > - as in the Sip Event RFC is not true for Refer ?? > > Reshmi > > > -----Original Message----- > From: Ranjit Avasarala [mailto:ranjit.avasarala@bplmail.com] > Sent: Friday, August 30, 2002 2:36 PM > To: Reshmi Nair; sip@ietf.org > Subject: Re: [Sip] Refer Final Response > > > Hi reshmi > > In case of call transfer, first u send 202 Accepted for REFER and u > send > a NOTIFY confirming that REFER was successful. > > > Ranjit > ----- Original Message ----- > From: Reshmi Nair > To: > Sent: Friday, August 30, 2002 1:24 PM > Subject: [Sip] Refer Final Response > > >> Hi, >> >> Quoting from RFC 3265 - SIP - Specific Event Notification, section > 3.1.4.1 : >> >> " A 200 response indicates that the subscription has been accepted and > that the user is authorized to subscribe to the requested resource. A > 202 response merely indicates that the subscription has been > understood, and that authorization may or may not have been granted. " >> >> Is this true for a refer subscription too ? Are we expected to send a >> 200 > OK for Refer, if authorization is successful before the transaction > times out ? >> All the call flows for refer only show a "202 Accepted" being sent as >> a > response to refer. That makes me wonder. >> >> Please let me know. >> >> Regards, >> Reshmi >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@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 Aug 30 09:49:10 2002 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 JAA17126 for ; Fri, 30 Aug 2002 09:49:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UDoC932362 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 09:50: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 g7UDnXo32337; Fri, 30 Aug 2002 09:49: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 g7UDlUo32263 for ; Fri, 30 Aug 2002 09:47:30 -0400 Received: from em.njupt.edu.cn (em.njupt.edu.cn [202.119.230.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16974 for ; Fri, 30 Aug 2002 09:45:49 -0400 (EDT) Message-Id: <200208301345.JAA16974@ietf.org> Received: (qmail 27116 invoked from network); 30 Aug 2002 14:04:20 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 30 Aug 2002 14:04:20 -0000 Date: Fri, 30 Aug 2002 21:55:37 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: Tirthankar Saha , "sip@ietf.org" Subject: Re: [Sip] Session Timer Issues and Proposal Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g7UDlUo32264 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, I think Tirthankar's words about session timer is reasonable, why doesn't any one give some comments? Best Regards. >Hello folks, > >I feel there are some issues with the Sip Session Timer spec and that it can >be >made simpler and more useful. I'm submitting a rough proposal for improving >the spec and would appreciate your comments. > >I haven't followed any previous discussions on this issue on the mailing >list, so I might be missing something. I thought that the shortcomings would >be addressed in a later version of the draft but it hasn't happened. So >before this draft attains RFC status like all the other ones, it's better >that we have another discussion on this topic. > >Regards, > >Tirthankar > >-------------------------------------------------------------- > >Issues: > >1) Why do we have to refresh the session with a re-INVITE? > >Lots of unnecessary processing for a simple keepalive. > - 3 way handshake > - sdp re-negotiation & possible re-opening of media channels > >This could have been justified earlier when the refresh-intervals were >recommended to be 30 mins. but this feature is now being considered to be >used for keeping the NAT bindings alive. This means that the >refresh-intervals are going to be as low as 30secs. > >I think using the re-INVITE to refresh a dialog is seriously flawed; I can't >think of any good reason for having this procedure. >We MUST address this issue ASAP. > > >2) Unnecessary processing & complications with "refresher" param. > >What do we gain by negotiating who's going to be the referesher? >On the other hand, extra work is required which can be avoided by having a >simple rule for deciding the refresher (ref. proposal below). This way we >can avoid the min-timer checks for DoS attacks and reduce interoperability >issues arising out >of certain non-conforming vendor implementations which don't use this param >at all. > >3) Unnecessary confusion with call-hold. > >There's no way to tell whether incoming re-INVITE is for session-refresh or >session-modification. > > e.g A & B in call & A is the refresher. Now, B holds the call and A is >still the refresher due to a specific case of negotiation >of refresher param. >If, A sends the refresh then B can't determine whether A is trying to modify >the session or refresh the session. B would reject the request (because he's >holding the call & won't allow A to unhold himself) & A MIGHT terminate the >call. > >4) No uniform strategy for dialog keep-alive : separate procedures for >INVITE,REGISTER & SUBSCRIBE/NOTIFY dialogs. > > >PROPOSAL >======== > >Common dialog-keepalive strategy though I've considered only INVITE dialogs. >Can be extended easily for other dialogs (I feel). > >New feature tag (for use in Supported,Require headers): > dtimer > >New Header > Dialog-Expires: > > - Can be included in ANY request and/or its response except BYE or > other requests terminating the dialog. > > - It MUST be included in the dialog-refresh request > which can be any valid request in the dialog although > the INFO request is recommended. > > - It is recommended that the UA intiating the dialog > SHOULD send this header in the initial INVITE. > > - If the request doesn't contain this header, the UAS can > add it in the response ONLY if the Supported header of > request contains the feature-tag "dtimer". > > - The endpoint (uac/uas) MUST include a supported header in > the message containing this header with the feature-tag "dtimer". > > - Proxies MUST NOT CHANGE this header. > > - Logic for determining the refresher: > > if (message contains "Supported: dtimer") > AND > ("Dialog-Expires" hdr present in the message) > { > > if (message is REQUEST) { > uac becomes the refresher > } else { > uas becomes the refresher > } > > } > else > { > feature disabled > } > > ie. whoever sends this hdr in a transaction first becomes > the refresher. > > - Logic for (re)starting expiry timer: > if (incoming-message contains "Dialog-Expires" header) > AND > (message contains Supported header with the > feature-tag "dtimer") > > - refresher role CANNOT be renegotiated. > > QUERY: Is this OK? Would renegotiation be needed in any case? > If yes, does it justify the extra renegotiation logic reqd.? > > - refresh & expiry time calculations are the same as in the > session-timer draft. > > > >SCENARIOS >========= >NOTE: INVITE dialog is assumed. >Endpoint A : Dialog initiator/Calling party/Initial UAC >Endpoint B : Called party/Initial UAS >Intermediate server S: proxy/B2BUA. > >1) Feature supported by BOTH endpoints. > > A includes "Dialog-Expires" header & "dtimer" in "Supported" > header in the initial INVITE request. B echoes the header in the > response and includes "dtimer" in the Supported header of > the response. As a result, A becomes the refresher. It sends the > refresh in INFO request which includes the "Dialog-Expires" header, > as a result of which B restarts the timer. > > 1.1) Refresh > A sends INFO request with "Dialog-Expires" header. > B restarts the expiry timer. > > 1.2) B goes down > A sends refresh and receives no response. > After timeout A sends BYE. > > 1.3) B goes down & comes up again > A sends refresh and receives 481 response. A sends BYE. > > 1.4) A goes down > B doesn't recv refreshes & sends BYE. > > 1.5) A holds the call and includes "Dialog-Expires" in the > re-INVITE to avoid sending extra message for refreshing the > dialog. B restarts the expiry timer upon receiving the re-INVITE. > > 1.6) On-the-wire: A & B send re-INVITE "simultaneously" > There would be a race condition if renegotiation was allowed > and both endpoints included the "Dialog-Expires" header in > the re-INVITEs. Since renegotiation is not allowed, A would > continue to be the refresher. > > >2) Feature supported ONLY by A & S > B doesn't send "Supported: dtimer" in response but S inserts it and > A starts the refresh timer. > >3) Feature supported ONLY by B & S > S inserts "Supported: dtimer" in the request and B inserts the > "Dialog-Expires" header & becomes the refresher. S removes the > "Dialog-Expires" header when forwarding the response to A. > >4) Feature supported ONLY by A > A doesn't recv "Supported: dtimer" in the response as neither B > nor S supports the feature and hence disables the feature. > >5) Feature supported ONLY by B > B doesn't recv "Supported: dtimer" in the request as neither A > nor S supports the feature and hence disables the feature. > >6) No endpt. support > Feature is disabled. > However, S can "query" the dialog-status by sending an INFO request > to all the endpoints in the dialog. It CAN release its resources if > any of the INFO requests elicit a 481 response or no answer. > This method can also be used by the UAs as an extra safety-check > although it is not recommended. > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@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 Aug 30 11:10:25 2002 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 LAA20689 for ; Fri, 30 Aug 2002 11:10:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UFBSZ04640 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 11:11:28 -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 g7UFAso04616; Fri, 30 Aug 2002 11:10:54 -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 g7UF79o04267 for ; Fri, 30 Aug 2002 11:07:09 -0400 Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20515 for ; Fri, 30 Aug 2002 11:05:34 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7UF6147026134 for ; Fri, 30 Aug 2002 11:06:02 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 10:06:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A640C4@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Fri, 30 Aug 2002 10:06:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Comment on Service Route Discovery 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 have a small comment on the Service Route Discovery draft (version -01). Section 6.1 omits important information about how the client behaves once a dialog is established. In particular: how does the route stored at registration time interact with the route stored when an INVITE response (or SUBSCRIBE response or NOTIFY request) is received which contains "Record-Route" headers? Does the "Record-Route" list *replace* the service route for subsequent requests in that dialog? (This would seem the most correct behavior). Similarly, if no "Record-Route" header is received, the client *ignores* the "Service-Route" header for the remainder of that dialog. A more consise way of saying this is: service routes apply *only* to requests sent outside of a dialog. This should also be expanded in the proxy section: when the proxy is included in a dialog-establishing message, it should make sure that it record-routes if it wants to receive messages for the remainder of the dialog. If we don't define the mechanism this way, then the proxies have no way to "drop out" of dialogs for which they have determined they no longer have an interest. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 30 11:11:22 2002 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 LAA20736 for ; Fri, 30 Aug 2002 11:11:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UFCQ004742 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 11:12: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 g7UFC6o04692; Fri, 30 Aug 2002 11:12:06 -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 g7UF8Do04551 for ; Fri, 30 Aug 2002 11:08:13 -0400 Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20547 for ; Fri, 30 Aug 2002 11:06:38 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g7U9Ho110902; Fri, 30 Aug 2002 04:17:52 -0500 Subject: RE: [Sip] Refer Final Response From: Robert Sparks To: Reshmi Nair Cc: Ranjit Avasarala , sip@ietf.org In-Reply-To: <860BFD79D602F0409BB9EEA42B9E3BC0279740@blr-m1-msg.wipro.com> References: <860BFD79D602F0409BB9EEA42B9E3BC0279740@blr-m1-msg.wipro.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 30 Aug 2002 10:06:23 -0500 Message-Id: <1030719992.1175.26.camel@dhcp132.dfw.dynamicsoft.com> Mime-Version: 1.0 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 response to the REFER is a statement about whether the UA is going to honor the REFER request or not. If you have knowledge that you will, in fact, attempt to contact the referenced resource before the REFER transaction expires, you can and should return a 200. If you are going to have to wait for a human or some other relatively slow authority to tell you whether or not its ok to try, you return a 202. A failed response tells you an implicit subscription won't be created. A success response tells you nothing about the implicit subscription however. That information is all contained in the initial NOTIFY. RjS On Fri, 2002-08-30 at 04:10, Reshmi Nair wrote: > Hi, > > Does that mean that : > " A 200 response indicates that the subscription has been accepted and > that the user is authorized to subscribe to the requested resource. A 202 > response merely indicates that the subscription has been understood, and > that authorization may or may not have been granted. " > > - as in the Sip Event RFC is not true for Refer ?? > > Reshmi > > > -----Original Message----- > From: Ranjit Avasarala [mailto:ranjit.avasarala@bplmail.com] > Sent: Friday, August 30, 2002 2:36 PM > To: Reshmi Nair; sip@ietf.org > Subject: Re: [Sip] Refer Final Response > > > Hi reshmi > > In case of call transfer, first u send 202 Accepted for REFER and u send > a NOTIFY confirming that REFER was successful. > > > Ranjit > ----- Original Message ----- > From: Reshmi Nair > To: > Sent: Friday, August 30, 2002 1:24 PM > Subject: [Sip] Refer Final Response > > > > Hi, > > > > Quoting from RFC 3265 - SIP - Specific Event Notification, section > 3.1.4.1 : > > > > " A 200 response indicates that the subscription has been accepted and > that the user is authorized to subscribe to the requested resource. A 202 > response merely indicates that the subscription has been understood, and > that authorization may or may not have been granted. " > > > > Is this true for a refer subscription too ? Are we expected to send a 200 > OK for Refer, if authorization is successful before the transaction times > out ? > > All the call flows for refer only show a "202 Accepted" being sent as a > response to refer. That makes me wonder. > > > > Please let me know. > > > > Regards, > > Reshmi > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@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 Aug 30 11:11:59 2002 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 LAA20781 for ; Fri, 30 Aug 2002 11:11:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UFD3404767 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 11:13: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 g7UFC9o04719; Fri, 30 Aug 2002 11:12: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 g7UFBAo04635 for ; Fri, 30 Aug 2002 11:11:10 -0400 Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20649 for ; Fri, 30 Aug 2002 11:09:35 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7UFA247026168; Fri, 30 Aug 2002 11:10:03 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 10:10:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A640C5@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Reshmi Nair'" , sip@ietf.org Subject: RE: [Sip] Refer Final Response Date: Fri, 30 Aug 2002 10:10:23 -0500 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: , The section you are quoting describes behavior for the SUBSCRIBE method. Behavior for the REFER method is described in the refer draft. /a > -----Original Message----- > From: Reshmi Nair [mailto:reshmi.nair@wipro.com] > Sent: Friday, August 30, 2002 2:54 > To: sip@ietf.org > Subject: [Sip] Refer Final Response > > > Hi, > > Quoting from RFC 3265 - SIP - Specific Event Notification, > section 3.1.4.1 : > > " A 200 response indicates that the subscription has been > accepted and that the user is authorized to subscribe to the > requested resource. A 202 response merely indicates that the > subscription has been understood, and that authorization may > or may not have been granted. " > > Is this true for a refer subscription too ? Are we expected > to send a 200 OK for Refer, if authorization is successful > before the transaction times out ? > All the call flows for refer only show a "202 Accepted" being > sent as a response to refer. That makes me wonder. > > Please let me know. > > Regards, > Reshmi > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@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 Aug 30 13:34:27 2002 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 NAA27000 for ; Fri, 30 Aug 2002 13:34:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UHZXP12235 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 13:35:33 -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 g7UHYao12206; Fri, 30 Aug 2002 13:34: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 g7UHWJo12163 for ; Fri, 30 Aug 2002 13:32:19 -0400 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26782 for ; Fri, 30 Aug 2002 13:30:40 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7UHVtrU001431; Fri, 30 Aug 2002 19:31:55 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g7UHVspk011290; Fri, 30 Aug 2002 20:31:55 +0300 (EET DST) Message-ID: <3D6FAC0A.BFD97A15@lmf.ericsson.se> Date: Fri, 30 Aug 2002 20:31:54 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: y01317@njupt.edu.cn CC: Tirthankar Saha , "sip@ietf.org" Subject: Re: [Sip] Session Timer Issues and Proposal References: <200208301345.JAA16974@ietf.org> 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, The session-timer has been discussed many times, during a very long time, so I think it would be a good to have a look at the archieves. I can't remember if all of the issues have been addressed, but at least some have. For example, the fact that INVITE is a very "heavy" thing to use for the session-timer has been brought up (by myself, among others) many times, and my understanding is that the UPDATE method will be added to the draft as an option for the session-timer. Using INFO has been discussed many times, and reasons have been given why it is not a very good solution. And, there IS a way of knowing if a re-INVITE is for a session modification, or simply for a session refresh - by checking the SDP. Regards, Christer Holmberg Ericsson Finland feng zhang wrote: > Hi, > > I think Tirthankar's words about session timer is reasonable, why doesn't any one > give some comments? > > Best Regards. > >Hello folks, > > > >I feel there are some issues with the Sip Session Timer spec and that it can > >be > >made simpler and more useful. I'm submitting a rough proposal for improving > >the spec and would appreciate your comments. > > > >I haven't followed any previous discussions on this issue on the mailing > >list, so I might be missing something. I thought that the shortcomings would > >be addressed in a later version of the draft but it hasn't happened. So > >before this draft attains RFC status like all the other ones, it's better > >that we have another discussion on this topic. > > > >Regards, > > > >Tirthankar > > > >-------------------------------------------------------------- > > > >Issues: > > > >1) Why do we have to refresh the session with a re-INVITE? > > > >Lots of unnecessary processing for a simple keepalive. > > - 3 way handshake > > - sdp re-negotiation & possible re-opening of media channels > > > >This could have been justified earlier when the refresh-intervals were > >recommended to be 30 mins. but this feature is now being considered to be > >used for keeping the NAT bindings alive. This means that the > >refresh-intervals are going to be as low as 30secs. > > > >I think using the re-INVITE to refresh a dialog is seriously flawed; I can't > >think of any good reason for having this procedure. > >We MUST address this issue ASAP. > > > > > >2) Unnecessary processing & complications with "refresher" param. > > > >What do we gain by negotiating who's going to be the referesher? > >On the other hand, extra work is required which can be avoided by having a > >simple rule for deciding the refresher (ref. proposal below). This way we > >can avoid the min-timer checks for DoS attacks and reduce interoperability > >issues arising out > >of certain non-conforming vendor implementations which don't use this param > >at all. > > > >3) Unnecessary confusion with call-hold. > > > >There's no way to tell whether incoming re-INVITE is for session-refresh or > >session-modification. > > > > e.g A & B in call & A is the refresher. Now, B holds the call and A is > >still the refresher due to a specific case of negotiation > >of refresher param. > >If, A sends the refresh then B can't determine whether A is trying to modify > >the session or refresh the session. B would reject the request (because he's > >holding the call & won't allow A to unhold himself) & A MIGHT terminate the > >call. > > > >4) No uniform strategy for dialog keep-alive : separate procedures for > >INVITE,REGISTER & SUBSCRIBE/NOTIFY dialogs. > > > > > >PROPOSAL > >======== > > > >Common dialog-keepalive strategy though I've considered only INVITE dialogs. > >Can be extended easily for other dialogs (I feel). > > > >New feature tag (for use in Supported,Require headers): > > dtimer > > > >New Header > > Dialog-Expires: > > > > - Can be included in ANY request and/or its response except BYE or > > other requests terminating the dialog. > > > > - It MUST be included in the dialog-refresh request > > which can be any valid request in the dialog although > > the INFO request is recommended. > > > > - It is recommended that the UA intiating the dialog > > SHOULD send this header in the initial INVITE. > > > > - If the request doesn't contain this header, the UAS can > > add it in the response ONLY if the Supported header of > > request contains the feature-tag "dtimer". > > > > - The endpoint (uac/uas) MUST include a supported header in > > the message containing this header with the feature-tag "dtimer". > > > > - Proxies MUST NOT CHANGE this header. > > > > - Logic for determining the refresher: > > > > if (message contains "Supported: dtimer") > > AND > > ("Dialog-Expires" hdr present in the message) > > { > > > > if (message is REQUEST) { > > uac becomes the refresher > > } else { > > uas becomes the refresher > > } > > > > } > > else > > { > > feature disabled > > } > > > > ie. whoever sends this hdr in a transaction first becomes > > the refresher. > > > > - Logic for (re)starting expiry timer: > > if (incoming-message contains "Dialog-Expires" header) > > AND > > (message contains Supported header with the > > feature-tag "dtimer") > > > > - refresher role CANNOT be renegotiated. > > > > QUERY: Is this OK? Would renegotiation be needed in any case? > > If yes, does it justify the extra renegotiation logic reqd.? > > > > - refresh & expiry time calculations are the same as in the > > session-timer draft. > > > > > > > >SCENARIOS > >========= > >NOTE: INVITE dialog is assumed. > >Endpoint A : Dialog initiator/Calling party/Initial UAC > >Endpoint B : Called party/Initial UAS > >Intermediate server S: proxy/B2BUA. > > > >1) Feature supported by BOTH endpoints. > > > > A includes "Dialog-Expires" header & "dtimer" in "Supported" > > header in the initial INVITE request. B echoes the header in the > > response and includes "dtimer" in the Supported header of > > the response. As a result, A becomes the refresher. It sends the > > refresh in INFO request which includes the "Dialog-Expires" header, > > as a result of which B restarts the timer. > > > > 1.1) Refresh > > A sends INFO request with "Dialog-Expires" header. > > B restarts the expiry timer. > > > > 1.2) B goes down > > A sends refresh and receives no response. > > After timeout A sends BYE. > > > > 1.3) B goes down & comes up again > > A sends refresh and receives 481 response. A sends BYE. > > > > 1.4) A goes down > > B doesn't recv refreshes & sends BYE. > > > > 1.5) A holds the call and includes "Dialog-Expires" in the > > re-INVITE to avoid sending extra message for refreshing the > > dialog. B restarts the expiry timer upon receiving the re-INVITE. > > > > 1.6) On-the-wire: A & B send re-INVITE "simultaneously" > > There would be a race condition if renegotiation was allowed > > and both endpoints included the "Dialog-Expires" header in > > the re-INVITEs. Since renegotiation is not allowed, A would > > continue to be the refresher. > > > > > >2) Feature supported ONLY by A & S > > B doesn't send "Supported: dtimer" in response but S inserts it and > > A starts the refresh timer. > > > >3) Feature supported ONLY by B & S > > S inserts "Supported: dtimer" in the request and B inserts the > > "Dialog-Expires" header & becomes the refresher. S removes the > > "Dialog-Expires" header when forwarding the response to A. > > > >4) Feature supported ONLY by A > > A doesn't recv "Supported: dtimer" in the response as neither B > > nor S supports the feature and hence disables the feature. > > > >5) Feature supported ONLY by B > > B doesn't recv "Supported: dtimer" in the request as neither A > > nor S supports the feature and hence disables the feature. > > > >6) No endpt. support > > Feature is disabled. > > However, S can "query" the dialog-status by sending an INFO request > > to all the endpoints in the dialog. It CAN release its resources if > > any of the INFO requests elicit a 481 response or no answer. > > This method can also be used by the UAs as an extra safety-check > > although it is not recommended. > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@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 Aug 30 14:20:54 2002 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 OAA29091 for ; Fri, 30 Aug 2002 14:20:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UIM0F14856 for sip-archive@odin.ietf.org; Fri, 30 Aug 2002 14:22: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 g7UIKUo14812; Fri, 30 Aug 2002 14:20: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 g7UIJTo14765 for ; Fri, 30 Aug 2002 14:19:29 -0400 Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28975 for ; Fri, 30 Aug 2002 14:17:51 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7UIHr47027270; Fri, 30 Aug 2002 14:17:54 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 13:18:25 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A640C6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Tirthankar Saha'" , SIP Mailing List Subject: RE: [Sip] Session Timer Issues and Proposal Date: Fri, 30 Aug 2002 13:18:18 -0500 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 haven't followed any previous discussions on this issue on > the mailing > list, so I might be missing something. This is somewhat understandable, since the discussion itself spans back to January of 1999. In fact, I started the conversation that led to the creation of the session-timer draft; see message <199901140349.VAA27266@b04a24.exu.ericsson.se> from the confctrl mailing list. I just re-read the ensuing discussion, and think it sheds a lot of light on why the decisions in this draft were made the way that they were. I encourage you to do the same, so as to gain some historical perspective. Most of the points you make were considered in some form at that time. (The confctrl archives are available in one 16 Mb blob from ftp://ftp.isi.edu/confctrl/confctrl.mail) > 1) Why do we have to refresh the session with a re-INVITE? > > Lots of unnecessary processing for a simple keepalive. > - 3 way handshake > - sdp re-negotiation & possible re-opening of media channels The early suggestions included a new method (PING) and the re-use of OPTIONS. The idea is that both of these would be sent by proxies, leading to an explosion of messages when many proxies were in the chain. OPTIONS had the additional failure that it could only determine UA liveness, not session state. I also suggested SUBSCRIBE/NOTIFY to something like session state (which we actually are developing a package for now!), but it suffers from the same message explosion problem. Further, speaking to the topic of using new methods, Dean objected: "Why do we keep reinventing new specialized methods like PING and INCALL and PRESENCE and so on . . . all these functions can be handled by simple, reuasable message primitives." > 2) Unnecessary processing & complications with "refresher" param. > > What do we gain by negotiating who's going to be the referesher? > On the other hand, extra work is required which can be > avoided by having a > simple rule for deciding the refresher (ref. proposal below). I remember that this was discussed on the list, and that the current mechanism reflects working group consensus at that time, but I don't rememeber the logic off the top of my head, and can't find the conversation. Perhaps someone else remembers. Jonathan? Steve? We could revisit this mechanism if it proves problematic, but your objection seems more aesthetic than technical in nature. > This way we can... reduce interoperability issues arising out > of certain non-conforming vendor implementations which don't > use this param at all. We can't really design a protocol to compensate for every moron out there who happens to get his hands on a compiler. Robustness is one thing; designing an idiot-proof protocol is another. The former is admirable, while the latter is impossible. > 3) Unnecessary confusion with call-hold. > > There's no way to tell whether incoming re-INVITE is for > session-refresh or > session-modification. Yes, there is. You examine the SDP. This is a non-argument. > 4) No uniform strategy for dialog keep-alive : separate procedures for > INVITE,REGISTER & SUBSCRIBE/NOTIFY dialogs. REGISTER doesn't create a dialog. In any case, registrations are soft state, and need to be refreshed with new REGISTERs. SUBSCRIBE dialogs naturally time out due to the soft-state nature of subscriptions. They need to be refreshed with new SUBSCRIBEs. The only reason we need session-timer for INVITE created sessions is that INVITEs don't have an inherent notion of timeouts that force refreshes. Session-timer fixes this by adding such a soft- state so that INVITE-created sessions need to be refreshed with (if you've followed the pattern of the previous two paragraphs, the next two words should be no surprise) new INVITEs. I'll try to make my point a little more obvious. You are arguing for a uniform strategy for keeping state fresh. +------------------+--------------------+ | State created by | State refreshed by | +------------------+--------------------+ | REGISTER | REGISTER | | SUBSCRIBE | SUBSCRIBE | | INVITE | INVITE | +------------------+--------------------+ In what way is this not uniform? > 6) No endpt. support > Feature is disabled. > However, S can "query" the dialog-status by sending an INFO request > to all the endpoints in the dialog. It CAN release its resources if > any of the INFO requests elicit a 481 response or no answer. > This method can also be used by the UAs as an extra safety-check > although it is not recommended. This suggestion has a host of problems that make it untenable. a) These queries would need to appear in-dialog; however, when S sends an INFO like this to B, he will use up CSeq space in that direction. Since A doesn't know about this message, the next message he sends has a high probability of being perceived as out-of-order and consequently rejected by B. b) Similarly, when B receives this request, he will perceive it as coming from A (because it's on a dialog he has with A). If he decides to challenge this request, S will have no way to respond. c) In a similar vein, if B requires A to sign and/or encrypt requests, any request by S will be rejected as forged or unreadable. d) This doesn't scale. As mentioned earlier, if you have long proxy chains with multiple proxies wanting to check liveness, you get huge volumes of traffic dedicated to checking dialog liveness. e) Ignoring the mechanism, allowing any third party -- even a proxy involved in the call -- to actively query dialog state without a clear way to implement policy has massive privacy problems. Now, that said, session-timer *is* in need of some updating to align with 3261 and 3264, as well as possibly making provisions for the UPDATE method. So, by all means, if you'd like to help in making revisions to accomodate these changes and make other improvements to the existing draft, I encourage it. You certainly seem to have the energy and time to dedicate to this effort. After over three and a half years of work acheiving some level of consensus on the current mechanism, though, I don't think it is rational to consider completely scrapping the existing work and starting from ground zero. We've discovered and fixed a lot of tricky problems already. If we start from scratch now, we'll spend a lot of time discovering and fixing these same and similar problems. I see no reason to begin afresh on this 44-month journey, only to be back where we are right now in June of 2007. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Aug 31 00:29:09 2002 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 AAA15184 for ; Sat, 31 Aug 2002 00:29:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7V4UKe11009 for sip-archive@odin.ietf.org; Sat, 31 Aug 2002 00:30: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 g7V4Too10950; Sat, 31 Aug 2002 00:29: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 g7V4RXo10876 for ; Sat, 31 Aug 2002 00:27:33 -0400 Received: from web12804.mail.yahoo.com (web12804.mail.yahoo.com [216.136.174.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14949 for ; Sat, 31 Aug 2002 00:25:52 -0400 (EDT) Message-ID: <20020831042723.21202.qmail@web12804.mail.yahoo.com> Received: from [63.249.65.235] by web12804.mail.yahoo.com via HTTP; Fri, 30 Aug 2002 21:27:23 PDT Date: Fri, 30 Aug 2002 21:27:23 -0700 (PDT) From: Hil To: sip@ietf.org In-Reply-To: <20020829160000.22484.25975.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] unsubscribe 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: , --- sip-request@ietf.org wrote: > Send Sip mailing list submissions to > sip@ietf.org > > To subscribe or unsubscribe via the World Wide Web, > visit > https://www1.ietf.org/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@ietf.org > > You can reach the person managing the list at > sip-admin@ietf.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Sip digest..." > > > Today's Topics: > > 1. RE: What's the Changes? (Dean Willis) > 2. asserted-identity-02 (Rohan Mahy) > 3. Record-route uri must be sip or sips > (hisham.khartabil@nokia.com) > 4. Session Timer Issues and Proposal (Tirthankar > Saha) > 5. Re: Record-route uri must be sip or sips > (Robert Sparks) > > --__--__-- > > Message: 1 > From: "Dean Willis" > To: , > Subject: RE: [Sip] What's the Changes? > Date: Wed, 28 Aug 2002 15:18:12 -0500 > > > Fixed two errors in the abnf that had been left over > from ripping out > the p- stuff. Clarified discussion of the relevance > of sip-change > process in the IANA considerations section. Cleaned > up some of the > wording around Alternatve 3 to say that the > referenced inbound routing > technique with look-up tables is used in some 3G > networks. > > In other words, it is very likely that you will > notice any change at all > unless you were one of the people who specifically > requested a change. > > -- > Dean > > > -----Original Message----- > > From: sip-admin@ietf.org > [mailto:sip-admin@ietf.org] On > > Behalf Of feng zhang > > Sent: Wednesday, August 28, 2002 8:00 AM > > To: sip@ietf.org > > Subject: [Sip] What's the Changes? > > > > > > Hi All, > > > > Who can tell me the CHANGES between > > draft-ietf-sip-scvrtdisco-00 and > draft-ietf-sip-scvrtdisco-01 ? > > > > Thanks a lot! > > > > Best Regards. > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current > > sip Use sipping@ietf.org for new developments on > the > > application of sip > > > > > > > --__--__-- > > Message: 2 > Date: Wed, 28 Aug 2002 18:49:19 -0700 > Cc: mankin@psg.com, fluffy@cisco.com, > jon.peterson@neustar.biz, > Mark Watson , > rohan@cisco.com > To: sip@ietf.org > From: Rohan Mahy > Subject: [Sip] asserted-identity-02 > > Hi Folks, > > As someone pointed out in Yokohama, the > asserted-identity-01 draft that > was in the archives then did not reflect WG > consensus on the matter of > separate header vs. same header for the hint. (This > was due to a > coordination SNAFU as the draft went to IESG > review.) The -02 version of > asserted identity that just appeared in the archive > corrected this > inconsistency. > > thanks, > -rohan > > > --__--__-- > > Message: 3 > From: hisham.khartabil@nokia.com > Date: Thu, 29 Aug 2002 10:10:14 +0300 > To: > Subject: [Sip] Record-route uri must be sip or sips > > Section 16.6 item 4 states that > > "The URI placed in the Record-Route header field > value MUST be a > SIP or SIPS URI" > > But the grammar for record-route allows absolute > URI. Why allow it in the grammar? > > Regards, > Hisham > > --__--__-- > > Message: 4 > From: "Tirthankar Saha" > To: "SIP Mailing List" > Date: Thu, 29 Aug 2002 15:58:09 +0530 > Subject: [Sip] Session Timer Issues and Proposal > > Hello folks, > > I feel there are some issues with the Sip Session > Timer spec and that it can > be > made simpler and more useful. I'm submitting a rough > proposal for improving > the spec and would appreciate your comments. > > I haven't followed any previous discussions on this > issue on the mailing > list, so I might be missing something. I thought > that the shortcomings would > be addressed in a later version of the draft but it > hasn't happened. So > before this draft attains RFC status like all the > other ones, it's better > that we have another discussion on this topic. > > Regards, > > Tirthankar > > -------------------------------------------------------------- > > Issues: > > 1) Why do we have to refresh the session with a > re-INVITE? > > Lots of unnecessary processing for a simple > keepalive. > - 3 way handshake > - sdp re-negotiation & possible re-opening of > media channels > > This could have been justified earlier when the > refresh-intervals were > recommended to be 30 mins. but this feature is now > being considered to be > used for keeping the NAT bindings alive. This means > that the > refresh-intervals are going to be as low as 30secs. > > I think using the re-INVITE to refresh a dialog is > seriously flawed; I can't > think of any good reason for having this procedure. > We MUST address this issue ASAP. > > > 2) Unnecessary processing & complications with > "refresher" param. > > What do we gain by negotiating who's going to be the > referesher? > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.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 Aug 31 04:39:02 2002 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 EAA28551 for ; Sat, 31 Aug 2002 04:39:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7V8eDn30143 for sip-archive@odin.ietf.org; Sat, 31 Aug 2002 04:40: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 g7V8dXo30092; Sat, 31 Aug 2002 04:39:34 -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 g7V8bVo30060 for ; Sat, 31 Aug 2002 04:37:31 -0400 Received: from ndc.vsnl.net.in (del3.vsnl.net.in [202.54.96.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28519 for ; Sat, 31 Aug 2002 04:35:47 -0400 (EDT) Received: from t (unknown [203.200.114.249]) by ndc.vsnl.net.in (Postfix) with SMTP id 2943E43CF8; Sat, 31 Aug 2002 08:36:13 +0000 (IST) Message-ID: <001101c250ca$d0f30ac0$f972c8cb@t> From: "Tirthankar Saha" To: "Adam Roach" , "SIP Mailing List" References: <9BF66EBF6BEFD942915B4D4D45C051F3A640C6@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] Session Timer Issues and Proposal Date: Sat, 31 Aug 2002 14:13:45 +0530 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, Thanks Adam and Christian for the comments. Christian, you are right, using the UPDATE method without SDP offer as recommended in the latest session-timer draft does resolve the main issue i.e. "heavy" processing for simple keep-alive. Adam, I don't think that the refresher param is a major issue and it's true that you can't ensure everyone to follow the spec but my point was it's better not to have extra options which don't provide anything useful. IMRHO the refresher param leads to unecessary DoS checks and processing. I'm searching the mailing lists for an answer to why we should continue with this param at all... in the meantime it'd be nice for SIP gurus to provide some info... > I'll try to make my point a little more obvious. You are arguing > for a uniform strategy for keeping state fresh. > > +------------------+--------------------+ > | State created by | State refreshed by | > +------------------+--------------------+ > | REGISTER | REGISTER | > | SUBSCRIBE | SUBSCRIBE | > | INVITE | INVITE | > +------------------+--------------------+ > > In what way is this not uniform? > Adam, it's true that the strategy is uniform but what I wanted to say is that we have to implement the same thing differently for different methods. It'd better having one single message which can refresh different types of dialogs/sessions. Consider the case of a dialog-stateful proxy: it has to be aware of the separate keep-alive mechanisms of SUBSCRIBE, INVITE etc. dialogs. Now suppose a new method is introduced with its own keep-alive mechanism, the proxy has to be updated to account for this. Regards, Tirthankar _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip