From sip-bounces@ietf.org Wed Nov 01 00:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf8Za-00059p-0g; Wed, 01 Nov 2006 00:23:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf8ZV-00051r-0l for sip@ietf.org; Wed, 01 Nov 2006 00:23:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf8ZT-0004SS-HJ for sip@ietf.org; Wed, 01 Nov 2006 00:23:28 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA14Qn8r015725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 22:26:50 -0600 In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E024D29E2@xmb-rtp-215.amer.cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E024D29E2@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4276CFA4-4BEB-4E84-ADBC-CB74B735D933@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 23:23:12 -0600 To: Sanjay Sinha ((sanjsinh)) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote: > > It is my understanding is that SBC is esentially a B2BUA or an IP-IP > gateway, if one leg is SIP and another one is say, H323/MGCP. A pstn > gateway is termination point of IP leg signaling. It will have fxs/ > pots > or a PBX interface on the other leg. So I can have an IAD with pots > phones hanging off of fxs port in a small branch office and know that > interface is secure/trusted. > Ok, that's fair. I wouldn't describe that as a PSTN Gateway so much as I would describe it as a multi-user UA that uses telephone handsets to implement its user interface devices. By the same token, it would be OK to run sips: to a Mac that uses a Bluetooth headset, even though Bluetooth isn't TLS. By PSTN gateway, I mean a box that converts the SIP call into a signaled call on a PSTN line (especially a "trunk" line). Of course, once you stick an fxo line on that multiuser-UA box and start pumping calls back into the P (that's Public) STN, you have a security problem again. This could easily happen with a PBX, so that could be a problem. It might be legit to say that a PBX simply can't do sips:, because it can't meet the security assurances of sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 00:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf8qL-0004mT-3d; Wed, 01 Nov 2006 00:40:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf8qI-0004mB-O2 for sip@ietf.org; Wed, 01 Nov 2006 00:40:50 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf8qH-0004mL-1X for sip@ietf.org; Wed, 01 Nov 2006 00:40:50 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id EFAA9AC27D; Wed, 1 Nov 2006 07:40:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17736.13150.868614.386775@harjus.tutpro.com> Date: Wed, 1 Nov 2006 07:40:46 +0200 To: "Samir Srivastava" Subject: RE: [Sip] Re: What consensus? In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F620799@zrc2hxm2.corp.nortel.com> References: <7.0.1.0.0.20061031170136.0355fa10@stevecrocker.com> <62B9B0847CC47543B6B3B5E26BD268E60F620799@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava writes: > SIP itself is too complex. IMHO, the more complexities you add to the > protocol, the less users you will get. See what major search engine > chose ? yes, they chose xmmp and that is where non-ims sip folks are heading to too. > People already started talking about mistakes of the SIP and paving the > way for new protocol. we already have got it. > Why IP surviving so long and being utilized for other purposes too? > Because the founders had the UNWAVERING commitment to RUNNING CODE and > they used to look for SIMPLICITY etc.. I don't want to go more details > here. yes, in sip things have been totally opposite. this working group has developed heaps of rfcs that no-one has implemented. -- 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 sip-bounces@ietf.org Wed Nov 01 03:33:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfBT9-00062T-GX; Wed, 01 Nov 2006 03:29:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfBT5-0005zY-E9 for sip@ietf.org; Wed, 01 Nov 2006 03:29:04 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfBT1-0000El-U5 for sip@ietf.org; Wed, 01 Nov 2006 03:29:03 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J810014KM89YR@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 08:28:57 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6CC5>; Wed, 01 Nov 2006 08:28:46 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 08:28:45 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Dean Willis , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F26670A3D8323@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, I think your proposal is moving in the right direction, but I have a couple of concerns. See below. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 31 October 2006 18:21 > To: IETF SIP List > Subject: [Sip] A sips: trial balloon for you to shoot down > > > Ok, let me make a proposal, or perhaps remake one somebody else has > made. I've lost track of who said what... > > I think we're now talking about a BCP for secure operations. > > 1) Implementations of SIP SHOULD use TLS as described in RFC > 3261 for > all SIP traffic, including traffic using a sip: URI scheme. Failure > to use TLS may result in disclosure of sensitive signaling > information to third parties. As a matter of local policy, some > deployments MAY use IPSEC or physically protected infrastructure > instead of TLS on specific links. Examples where this might be > appropriate include persistent IPSEC relationships between proxies > within an operational domain and physically protected "private > network" cables between a TLS concentrator and the device it is > fronting for. Where TLS is not used, the implementor MUST exercise a > high level of caution to provide adequate security and MUST preserve > operationally equivalent protection of message integrity, privacy, > and participant identity (authentication). [JRE] Whilst I agree with the above, I am concerned that the UAs involved will not know whether best effort has resulting in a signalling path that is secure on all hops. Why do I want to know? Suppose I have feature X that somehow relies on all hops being secure. If I want the request to fail if I can't use feature X, then I use SIPS. However, if I want the request to succeed even if I can't use feature X (because some hops are insecure), then I need some indication of whether all hops are secure or not, and then I can decide whether to use feature X. Giving an example of a feature X is not so easy, but one possibility could be identity. I might anonymise the From header in a SIP request, and then, if it results in a dialog that is secure, I might use connected-identity to change the From header field URI mid-dialog. As another example of a feature X, maybe I am prepared to use media security using SDescriptions if the dialog is secured, without using S/MIME. Therefore I find the dialog is secure I re-negotiate the session, this time with SDescriptions. > > 2) When using the sips: URI scheme, implementations MUST NOT > exercise > the "last hop exception" for sips: processing described in RFC 3261. > Most scenarios where this technique might have seemed > appropriate can > be better satisfied using a client-initiated TLS connection as > described in draft-ietf-sip-outbound. User agents that do not > implement both TLS and either terminate TLS connections or exercise > draft-ietf-sip-outbound with a US-originated TOS connection to an > outbound will therefore not be able to exercise the sips: URI > scheme. > Failure to observe this requirement is likely to result in a > reduction of operational security below that expected from the sips: > URI scheme. > > 3) Since some user-agents will not be able to exercise the sips: > scheme, implementations MUST anticipate the failure of sips: > requests > and in general SHOULD use sips: only when it is desired that the > request will not complete unless TLS will be used on each hop. Since > requests using the sip: URI scheme are (by requirement 1 above) > expected to be as securely processed as the implementation is > able to > do, it is not suggested that one first try sips: and then > back off to > sip:. In other words, if you're willing to settle for the best > security that can actually be provided, simply originate the request > with a sip: URI scheme. > > 4) User agent servers that terminate a request using the sips: URI > scheme MUST create any dependent requests using the sips: URI > scheme. > This preserves the commitments of the sips: scheme, and failure to > observe this constraint would give the appearance of sips: security > where no such security exists. For example, this requirement means > that that back-to-back user agents bridging two sips: requests use > sips: on both sides. Furthermore, gateways to other protocols not > offering equally strong protections MUST NOT exercise the sips: URI > scheme. In particular, PSTN gateways MUST NOT use sips:, since the > PSTN itself does not offer equivalent protections and there is no > ability to determine whether the PSTN segment might be > converted back > to a sip: request somewhere downstream. [JRE] As I stated in one of the related threads, I think SIPS should govern hops as far as the PSTN gateway, and the potential insecurity of whatever is beyond that gateway should be signalled by other means. Achieving a SIPS connection as far as the gateway might allow me to use SDescriptions to achieve media security to that gateway. I can't do much about what is beyond the gateway, but a separate indicator that says that it might not be secure would allow me, for example, to suppress the security padlock. > > > -- > 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 sip-bounces@ietf.org Wed Nov 01 06:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfE8U-0006FI-SR; Wed, 01 Nov 2006 06:19:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDTw-00037V-L3 for sip@ietf.org; Wed, 01 Nov 2006 05:38:05 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfDTv-0007K7-B6 for sip@ietf.org; Wed, 01 Nov 2006 05:38:04 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8100C6IS6FJQ@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 10:37:28 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6FPC>; Wed, 01 Nov 2006 10:37:17 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 10:37:15 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: Francois Audet , Juha Heinanen Message-id: <50B1CBA96870A34799A506B2313F26670A3D85A8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 31 October 2006 16:48 > To: Juha Heinanen; Elwell, John > Cc: Joel M. Halpern; IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > > > > -----Original Message----- > > From: Juha Heinanen [mailto:jh@tutpro.com] > > Sent: Tuesday, October 31, 2006 1:30 AM > > To: Elwell, John > > Cc: Joel M. Halpern; 'IETF SIP List' > > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > > TLS meaning) > > > > Elwell, John writes: > > > > > TLS is not available. So a SIPS request would get > > rejected. Now this is fine > if the caller is interested in > > making the call only if it can be a secure > call (whatever > > that means), but in many cases the caller would want to > > > accept an insecure call and the UAC would have to try again > > with > SIP. > > > > i don't think that signaling security alone without media > > security means anything to common users. this is further > > justification of dropping sips. > > That is absolute rubish. > > There are cases where you want signalling to be secure (for > authentication, impersonation, theft of service, etc.), but you don't > need, > or want, or even can have encrypted media. [JRE] No, but you might want authenticated media. It is all very well saying that the signalling comes from the person you think it comes from, but if the media is coming from somewhere else, that doesn't help the average user. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 06:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEAt-0003ta-Ni; Wed, 01 Nov 2006 06:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfDsA-000813-2x for sip@ietf.org; Wed, 01 Nov 2006 06:03:06 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfDpE-0001fU-Ov for sip@ietf.org; Wed, 01 Nov 2006 06:00:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 11:00:01 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3626@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down thread-index: Acb9Gbo1CRv4RWfrT6y88QmXDH1kcwAimGSg From: "Attila Sipos" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Furthermore, gateways to other protocols not =20 >> offering equally strong protections MUST NOT exercise the sips: URI =20 >> scheme. In particular, PSTN gateways MUST NOT use sips:, since the =20 >> PSTN itself does not offer equivalent protections and there is no =20 >> ability to determine whether the PSTN segment might be=20 >> converted back to a sip: request somewhere downstream. I don't think you will get agreement on this. I think this rule will have to be very different. Instead of saying that we MUST or MUST NOT, it should be a section on making readers aware of the security implications. In my opinion, it's a policy thing, not a standards thing. There is a benefit in having secure SIP being used upto the PSTN gateway. Regards, Attila _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 06:55:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEdt-0004vW-LY; Wed, 01 Nov 2006 06:52:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEds-0004u9-6P for sip@ietf.org; Wed, 01 Nov 2006 06:52:24 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfEdp-0003Jl-8q for sip@ietf.org; Wed, 01 Nov 2006 06:52:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kA1BqJkc084128 for ; Wed, 1 Nov 2006 11:52:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA1BtDJK3055632 for ; Wed, 1 Nov 2006 12:55:13 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA1BqJ68028057 for ; Wed, 1 Nov 2006 12:52:19 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA1BqJhV028052 for ; Wed, 1 Nov 2006 12:52:19 +0100 In-Reply-To: <6205D258-12AB-42FD-9986-186E74901246@softarmor.com> To: sip@ietf.org MIME-Version: 1.0 Subject: Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 1 Nov 2006 13:55:09 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 01/11/2006 13:55:12, Serialize complete at 01/11/2006 13:55:12 X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0838225123==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0838225123== Content-Type: multipart/alternative; boundary="=_alternative 00413D64C2257219_=" This is a multipart message in MIME format. --=_alternative 00413D64C2257219_= Content-Type: text/plain; charset="US-ASCII" Seems that we need a mechanism to create a trusted "channel" between endpoints that goes through all the intermediaries. The channel should verifiable as secure between the endpoints. After the channel is created then the SIP signalling can go securely over the channel. The protocol for creating such a channel may be SIP based on external to SIP and after we have such a mechanism we can decide if we will use SIPS for messages that need to go over the secure channel or we will use new URI type (e.g. SSIP) or just use some header in the SIP message. The other alternative is the usage of S/MIME which has its drawbacks as we can see in another thread. Other then a secure channel or S/MIME I do not think that it will be possible to send a SIP message and get real assurance that the message will be sent securely in every hop. --Avshalom Dean Willis 31/10/2006 18:51 To Michael Thomas cc "Joel M. Halpern" , "'IETF SIP List'" , Juha Heinanen , "Elwell, John" Subject Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: > My advise to the working group is to just start over from first > principles as if > SIPS didn't even exist -- which in reality it doesn't. We need to > be thinking > about these things for the long term, and if it's not baked it's > not baked. There > have been many drafts that have lingered on and completely > overhauled over > the years. Why SIPS is treated so differently in that respect is > somewhat > mystifying because dealing with security for SIP is a genuinely > hard problem. > It shouldn't be rushed, and it deserves better than a kludgey > security patina > airbrushed in to get past the IESG. I'm very tempted to endorse this, but I think you're missing one thing. Flimsy as it is, I believe that sips: is as strong as the rest of the current SIP security model since it depends on the same trust assumptions. We can't just restart on sips: without restarting from those fundamental trust assumptions. This is not trivial. Many people would argue that it would turn SIP into a fundamentally different protocol. I think it needs to be done, but I also think we need to clearly document how the current trust model (including sips:) works, because that's what's going to be deployed in the real world for a relatively long time. The P2PSIP work is having to re-examine those fundamental trust assumptions. My current hope is we can do some work there that can be "ported back" into SIP. -- 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 --=_alternative 00413D64C2257219_= Content-Type: text/html; charset="US-ASCII"
Seems that we need a mechanism to create a trusted "channel" between
endpoints that goes through all the intermediaries. The channel should
verifiable as secure between the endpoints. After the channel is created
then the SIP signalling can go securely over the channel.

The protocol for creating such a channel may be SIP based on
external to SIP and after we have such a mechanism we can decide if we
will use SIPS for messages that need to go over the secure channel
or we will use new URI type (e.g. SSIP) or just use some
header in the SIP message.

The other alternative is the usage of S/MIME which has its drawbacks as
we can see in another thread.

Other then a secure channel or S/MIME I do not think that it will be
possible to send a SIP message and get real assurance that the message
will be sent securely in every hop.

--Avshalom



Dean Willis <dean.willis@softarmor.com>

31/10/2006 18:51

To
Michael Thomas <mat@cisco.com>
cc
"Joel M. Halpern" <joel@stevecrocker.com>, "'IETF SIP List'" <sip@ietf.org>, Juha Heinanen <jh@tutpro.com>, "Elwell, John" <john.elwell@siemens.com>
Subject
Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip]        RE: TLS meaning))






On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote:

> My advise to the working group is to just start over from first  
> principles as if
> SIPS didn't even exist -- which in reality it doesn't. We need to  
> be thinking
> about these things for the long term, and if it's not baked it's  
> not baked. There
> have been many drafts that have lingered on and completely  
> overhauled over
> the years. Why SIPS is treated so differently in that respect is  
> somewhat
> mystifying because dealing with security for SIP is a genuinely  
> hard problem.
> It shouldn't be rushed, and it deserves better than a kludgey  
> security patina
> airbrushed in to get past the IESG.

I'm very tempted to endorse this, but I think you're missing one thing.

Flimsy as it is, I believe that sips: is as strong as the rest of the  
current SIP security model since it depends on the same trust  
assumptions.

We can't just restart on sips: without restarting from those  
fundamental trust assumptions.

This is not trivial. Many people would argue that it would turn SIP  
into a fundamentally different protocol. I think it needs to be done,  
but I also think we need to clearly document how the current trust  
model (including sips:) works, because that's what's going to be  
deployed in the real world for a relatively long time.

The P2PSIP work is having to re-examine those fundamental trust  
assumptions. My current hope is we can do some work there that can be  
"ported back" into SIP.

--
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
--=_alternative 00413D64C2257219_=-- --===============0838225123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0838225123==-- From sip-bounces@ietf.org Wed Nov 01 06:59:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEiG-0008Rf-T3; Wed, 01 Nov 2006 06:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEiF-0008RM-1y for sip@ietf.org; Wed, 01 Nov 2006 06:56:55 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfEiB-0004OW-Jl for sip@ietf.org; Wed, 01 Nov 2006 06:56:55 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1BuHAB016668; Wed, 1 Nov 2006 13:56:47 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:55:21 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:55:19 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Date: Wed, 1 Nov 2006 13:55:20 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F019756B2@esebe103.NOE.Nokia.com> In-Reply-To: <007001c6faa9$6a1c1480$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Thread-Index: Acb6qwvz3POMtKjjRwuYW4FwCrW70ADAOVqQ From: To: , X-OriginalArrivalTime: 01 Nov 2006 11:55:19.0937 (UTC) FILETIME=[9AC3E710:01C6FDAC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101135647-3F276BB0-5510B422/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0538565337==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0538565337== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FDAC.9B40F133" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FDAC.9B40F133 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Actually I did not understand why the reg-id should be encoded into this = URI at all. =20 Could you please clarify the reason for its presence ? Or could the URI = be constructed without the reg-id included to any part of the URI ? =20 Regards, =20 Erkki -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 28 October, 2006 18:55 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: [Sip] mid-dialog failover: need URI parameter for reg-id to = avoidtriangular routing Jonathan, =20 Regarding your outbound-discovery-mid-dialog draft: I believe it can = work, but the example given in section 15 has some glitches and may = result in sub-optimal routing. =20 The backup flow from the UA x should have a different reg-id, say = reg-id=3D*2* (instead of 1 as per the example in the draft). Assume = there is also a user y registered, via proxy 1 and proxy 3. Then the = connection table at the home proxy would look like =20 TLS connection to 1: sip:outbound.example.com = sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun TLS connection to 2: sip:outbound.example.com = sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun =20 TLS connection to 3: sip:outbound.example.com = sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun = sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun= =20 Consequently, when proxy 2 fails, there will be no "most specific" match = for message 35, only least specific ones. The request should go to proxy = 3, but the home proxy could equally likely select proxy 1 (which would = then perform triangular routing via proxy 2).=20 =20 To have the home proxy favor proxy 3 in this scenario, I believe we need = a URI parameter to hold the reg-id, instead of putting it in the user = part. If we would then define that flow selection should be performed = based on the URI from which the reg-id parameter is stripped, there = would be a partly specific match for proxy 3 and failover would work = more smoothly =20 Regards, Jeroen ------_=_NextPart_001_01C6FDAC.9B40F133 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Actually I did not understand why the reg-id should be encoded = into this=20 URI at all.
 
Could=20 you please clarify the reason for its presence ? Or could the URI be=20 constructed
without the reg-id included to any part of the URI = ?
 
Regards,
 
Erkki
-----Original Message-----
From: ext Jeroen van = Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 28 October, 2006=20 18:55
To: Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: [Sip] mid-dialog failover: need URI = parameter=20 for reg-id to avoidtriangular routing

Jonathan,
 
Regarding your = outbound-discovery-mid-dialog=20 draft: I believe it can work, but the example given in section 15 has = some=20 glitches and may result in sub-optimal routing.
 
The backup flow from the UA x should = have a=20 different reg-id, say reg-id=3D*2* (instead of 1 as per the example in = the=20 draft). Assume there is also a user y registered, via proxy 1 and = proxy 3.=20 Then the connection table at the = home proxy=20 would look like
 
TLS connection to = 1:
   =20 sip:outbound.example.com
   =20 = sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun

TLS connection to 2:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun
 
TLS connection to = 3:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun<= /FONT>
   =20 = sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun=
 
Consequently, when proxy 2 fails, = there will be=20 no "most specific" match for message 35, only least specific ones. The = request=20 should go to proxy 3, but the home proxy could equally likely select = proxy 1=20 (which would then perform triangular routing via proxy 2). =
 
To have the home proxy favor proxy 3 = in this=20 scenario, I believe we need a URI parameter to hold the reg-id, = instead of=20 putting it in the user part. If we would then define that flow = selection=20 should be performed based on the URI from which the reg-id parameter = is=20 stripped, there would be a partly specific match for proxy 3 and = failover=20 would work more smoothly
 
Regards,
Jeroen
------_=_NextPart_001_01C6FDAC.9B40F133-- --===============0538565337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0538565337==-- From sip-bounces@ietf.org Wed Nov 01 07:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEnM-0005Vc-80; Wed, 01 Nov 2006 07:02:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfEnL-0005UR-3A for sip@ietf.org; Wed, 01 Nov 2006 07:02:11 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfEnH-0005Vm-8T for sip@ietf.org; Wed, 01 Nov 2006 07:02:11 -0500 Received: (qmail 29362 invoked by uid 0); 1 Nov 2006 12:01:49 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Nov 2006 12:01:49 -0000 Message-ID: <009601c6fdad$8b2d5010$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F019756B2@esebe103.NOE.Nokia.com> Subject: Re: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Date: Wed, 1 Nov 2006 13:02:03 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594008352==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0594008352== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C6FDB5.ECC6D780" This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C6FDB5.ECC6D780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Erkii, The idea is to create 'stickiness', to prefer using the same flow for all requests unless it fails. So in order of decreasing preference: 1. Flow with same reg-id 2. Flow with other reg-id 3. Flow towards same FQDN (proxy cluster) Note that the matching algorithm I describe below is incomplete, what is needed is a set of rules that result in the above order of preference (in other words, binary equality is insufficient, we need multiple degrees of equality i.e. exact match, partly specific match, weak match (sam FQDN) and no match) Regards, Jeroen ----- Original Message ----- From: Erkki.Koivusalo@nokia.com To: jbemmel@zonnet.nl ; jdrosen@cisco.com Cc: sip@ietf.org Sent: Wednesday, November 01, 2006 12:55 PM Subject: RE: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Hi, Actually I did not understand why the reg-id should be encoded into this URI at all. Could you please clarify the reason for its presence ? Or could the URI be constructed without the reg-id included to any part of the URI ? Regards, Erkki -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 28 October, 2006 18:55 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Jonathan, Regarding your outbound-discovery-mid-dialog draft: I believe it can work, but the example given in section 15 has some glitches and may result in sub-optimal routing. The backup flow from the UA x should have a different reg-id, say reg-id=*2* (instead of 1 as per the example in the draft). Assume there is also a user y registered, via proxy 1 and proxy 3. Then the connection table at the home proxy would look like TLS connection to 1: sip:outbound.example.com sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=stun TLS connection to 2: sip:outbound.example.com sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun TLS connection to 3: sip:outbound.example.com sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=stun sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=stun Consequently, when proxy 2 fails, there will be no "most specific" match for message 35, only least specific ones. The request should go to proxy 3, but the home proxy could equally likely select proxy 1 (which would then perform triangular routing via proxy 2). To have the home proxy favor proxy 3 in this scenario, I believe we need a URI parameter to hold the reg-id, instead of putting it in the user part. If we would then define that flow selection should be performed based on the URI from which the reg-id parameter is stripped, there would be a partly specific match for proxy 3 and failover would work more smoothly Regards, Jeroen ------=_NextPart_000_0092_01C6FDB5.ECC6D780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Erkii,
 
The idea is to create 'stickiness', to = prefer using=20 the same flow for all requests unless it fails. So in order of = decreasing=20 preference:
1. Flow with same reg-id
2. Flow with other reg-id
3. Flow towards same FQDN (proxy=20 cluster)
 
Note that the matching algorithm I = describe below=20 is incomplete, what is needed is a set of rules that result in the above = order=20 of preference (in other words, binary equality is insufficient, we need = multiple=20 degrees of equality i.e. exact match, partly specific match, weak match = (sam=20 FQDN) and no match)
 
Regards,
Jeroen
----- Original Message -----
From:=20 Erkki.Koivusalo@nokia.com =
To: jbemmel@zonnet.nl ; jdrosen@cisco.com=20
Sent: Wednesday, November 01, = 2006 12:55=20 PM
Subject: RE: [Sip] mid-dialog = failover:=20 need URI parameter for reg-id to avoidtriangular routing

Hi,
 
Actually I did not understand why the reg-id should be = encoded into=20 this URI at all.
 
Could you please clarify the reason for its presence ? Or = could the URI=20 be constructed
without the reg-id included to any part of the URI=20 ?
 
Regards,
 
Erkki
-----Original Message-----
From: ext Jeroen van = Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 28 October, 2006=20 18:55
To: Jonathan Rosenberg
Cc: sip@ietf.org
Subject: = [Sip]=20 mid-dialog failover: need URI parameter for reg-id to = avoidtriangular=20 routing

Jonathan,
 
Regarding your = outbound-discovery-mid-dialog=20 draft: I believe it can work, but the example given in section 15 = has some=20 glitches and may result in sub-optimal routing.
 
The backup flow from the UA x = should have a=20 different reg-id, say reg-id=3D*2* (instead of 1 as per the example = in the=20 draft). Assume there is also a user y registered, via proxy 1 and = proxy 3.=20 Then the connection table at the = home proxy=20 would look like
 
TLS connection to = 1:
   =20 sip:outbound.example.com
   =20 = sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun

TLS connection to 2:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun
 
TLS connection to = 3:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun<= /FONT>
   =20 = sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun=
 
Consequently, when proxy 2 fails, = there will be=20 no "most specific" match for message 35, only least specific ones. = The=20 request should go to proxy 3, but the home proxy could equally = likely select=20 proxy 1 (which would then perform triangular routing via proxy 2).=20
 
To have the home proxy favor proxy = 3 in this=20 scenario, I believe we need a URI parameter to hold the reg-id, = instead of=20 putting it in the user part. If we would then define that flow = selection=20 should be performed based on the URI from which the reg-id parameter = is=20 stripped, there would be a partly specific match for proxy 3 and = failover=20 would work more smoothly
 
Regards,
Jeroen
------=_NextPart_000_0092_01C6FDB5.ECC6D780-- --===============0594008352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0594008352==-- From sip-bounces@ietf.org Wed Nov 01 07:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfFWJ-0002Zc-Ln; Wed, 01 Nov 2006 07:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfFWI-0002Yp-Me for sip@ietf.org; Wed, 01 Nov 2006 07:48:38 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfFWD-00055T-Nu for sip@ietf.org; Wed, 01 Nov 2006 07:48:38 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA1ChkXt006473; Wed, 1 Nov 2006 14:48:18 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:47:54 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:47:52 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Date: Wed, 1 Nov 2006 14:47:53 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F019756B4@esebe103.NOE.Nokia.com> In-Reply-To: <009601c6fdad$8b2d5010$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Thread-Index: Acb9rbxKjsK0vykWQ7iNNLSgJSsLEgABVMxg From: To: , X-OriginalArrivalTime: 01 Nov 2006 12:47:52.0519 (UTC) FILETIME=[F1D9BD70:01C6FDB3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2020145620==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2020145620== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FDB3.F2492DD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FDB3.F2492DD1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeroen, =20 But when reading the overview of the draft I came to a different = understanding about the 'stickness' that this draft is trying to achieve. In order of = decreasing preference: =20 1. The specific flow used for a dialog as indicated by the URI = parameters added into Record-Route 2. Any flow registered by the UA as indicated by the user part of the = URI as added to Path & S-R 3. Any proxy within the cluster as indicated by the host part of the URI = as in initial REGISTER =20 I did not find reg-id to be significant in any of those three options. = The instance-id (together with username and the selected proxies for the outbound-proxy-set) is = sufficient to identify any existing flow (as for item 2). =20 In which use case a proxy should be able to prefer a specific flow with = a specific reg-id ? I did not find any such use case in the draft. =20 Regards, =20 Erkki -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 01 November, 2006 14:02 To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); jdrosen@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] mid-dialog failover: need URI parameter for reg-id to = avoidtriangular routing Erkii, =20 The idea is to create 'stickiness', to prefer using the same flow for = all requests unless it fails. So in order of decreasing preference: 1. Flow with same reg-id 2. Flow with other reg-id 3. Flow towards same FQDN (proxy cluster) =20 Note that the matching algorithm I describe below is incomplete, what is = needed is a set of rules that result in the above order of preference = (in other words, binary equality is insufficient, we need multiple = degrees of equality i.e. exact match, partly specific match, weak match = (sam FQDN) and no match) =20 Regards, Jeroen ----- Original Message -----=20 From: Erkki.Koivusalo@nokia.com=20 To: jbemmel@zonnet.nl ; jdrosen@cisco.com=20 Cc: sip@ietf.org=20 Sent: Wednesday, November 01, 2006 12:55 PM Subject: RE: [Sip] mid-dialog failover: need URI parameter for reg-id to = avoidtriangular routing Hi, =20 Actually I did not understand why the reg-id should be encoded into this = URI at all. =20 Could you please clarify the reason for its presence ? Or could the URI = be constructed without the reg-id included to any part of the URI ? =20 Regards, =20 Erkki -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 28 October, 2006 18:55 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: [Sip] mid-dialog failover: need URI parameter for reg-id to = avoidtriangular routing Jonathan, =20 Regarding your outbound-discovery-mid-dialog draft: I believe it can = work, but the example given in section 15 has some glitches and may = result in sub-optimal routing. =20 The backup flow from the UA x should have a different reg-id, say = reg-id=3D*2* (instead of 1 as per the example in the draft). Assume = there is also a user y registered, via proxy 1 and proxy 3. Then the = connection table at the home proxy would look like =20 TLS connection to 1: sip:outbound.example.com = sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun TLS connection to 2: sip:outbound.example.com = sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun =20 TLS connection to 3: sip:outbound.example.com = sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun = sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun= =20 Consequently, when proxy 2 fails, there will be no "most specific" match = for message 35, only least specific ones. The request should go to proxy = 3, but the home proxy could equally likely select proxy 1 (which would = then perform triangular routing via proxy 2).=20 =20 To have the home proxy favor proxy 3 in this scenario, I believe we need = a URI parameter to hold the reg-id, instead of putting it in the user = part. If we would then define that flow selection should be performed = based on the URI from which the reg-id parameter is stripped, there = would be a partly specific match for proxy 3 and failover would work = more smoothly =20 Regards, Jeroen ------_=_NextPart_001_01C6FDB3.F2492DD1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Jeroen,
 
But=20 when reading the overview of the draft I came to a different = understanding=20 about
the=20 'stickness' that this draft is trying to achieve. In order of decreasing = preference:
 
1. The specific flow used for a dialog as = indicated by the=20 URI parameters added into Record-Route
2. Any=20 flow registered by the UA as indicated by the user part of the URI as = added to=20 Path & S-R
3. Any=20 proxy within the cluster as indicated by the host part of the URI as in = initial=20 REGISTER
 
I did=20 not find reg-id to be significant in any of those three options. The = instance-id=20 (together
with=20 username and the selected proxies for the outbound-proxy-set) is = sufficient to=20 identify
any=20 existing flow (as for item 2).
 
In=20 which use case a proxy should be able to prefer a specific flow with a = specific=20 reg-id ?
I did=20 not find any such use case in the draft.
 
Regards,
 
Erkki
-----Original Message-----
From: ext Jeroen van = Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 01 November, 2006=20 14:02
To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki);=20 jdrosen@cisco.com
Cc: sip@ietf.org
Subject: Re: = [Sip]=20 mid-dialog failover: need URI parameter for reg-id to avoidtriangular=20 routing

Erkii,
 
The idea is to create 'stickiness', = to prefer=20 using the same flow for all requests unless it fails. So in order of=20 decreasing preference:
1. Flow with same reg-id
2. Flow with other = reg-id
3. Flow towards same FQDN (proxy=20 cluster)
 
Note that the matching algorithm I = describe below=20 is incomplete, what is needed is a set of rules that result in the = above order=20 of preference (in other words, binary equality is insufficient, we = need=20 multiple degrees of equality i.e. exact match, partly specific match, = weak=20 match (sam FQDN) and no match)
 
Regards,
Jeroen
----- Original Message -----
From:=20 Erkki.Koivusalo@nokia.com =
To: jbemmel@zonnet.nl ; jdrosen@cisco.com
Sent: Wednesday, November 01, = 2006=20 12:55 PM
Subject: RE: [Sip] mid-dialog = failover:=20 need URI parameter for reg-id to avoidtriangular routing

Hi,
 
Actually I did not understand why the reg-id should be = encoded into=20 this URI at all.
 
Could you please clarify the reason for its presence ? Or = could the=20 URI be constructed
without the reg-id included to any part of the URI=20 ?
 
Regards,
 
Erkki
-----Original Message-----
From: ext Jeroen van = Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 28 October, 2006=20 18:55
To: Jonathan Rosenberg
Cc: sip@ietf.org
Subject: = [Sip]=20 mid-dialog failover: need URI parameter for reg-id to = avoidtriangular=20 routing

Jonathan,
 
Regarding your = outbound-discovery-mid-dialog=20 draft: I believe it can work, but the example given in section 15 = has some=20 glitches and may result in sub-optimal routing.
 
The backup flow from the UA x = should have a=20 different reg-id, say reg-id=3D*2* (instead of 1 as per the = example in the=20 draft). Assume there is also a user y registered, via proxy 1 and = proxy 3.=20 Then the connection table at = the home proxy=20 would look like
 
TLS connection to = 1:
   =20 sip:outbound.example.com
   =20 = sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun

TLS connection to 2:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun
 
TLS connection to = 3:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun<= /FONT>
   =20 = sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun=
 
Consequently, when proxy 2 fails, = there will=20 be no "most specific" match for message 35, only least specific = ones. The=20 request should go to proxy 3, but the home proxy could equally = likely=20 select proxy 1 (which would then perform triangular routing via = proxy 2).=20
 
To have the home proxy favor = proxy 3 in this=20 scenario, I believe we need a URI parameter to hold the reg-id, = instead of=20 putting it in the user part. If we would then define that flow = selection=20 should be performed based on the URI from which the reg-id = parameter is=20 stripped, there would be a partly specific match for proxy 3 and = failover=20 would work more smoothly
 
Regards,
Jeroen
------_=_NextPart_001_01C6FDB3.F2492DD1-- --===============2020145620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2020145620==-- From sip-bounces@ietf.org Wed Nov 01 08:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGWQ-0001aS-Gs; Wed, 01 Nov 2006 08:52:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGWO-0001aL-CH for sip@ietf.org; Wed, 01 Nov 2006 08:52:48 -0500 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfGWK-0001Vv-Bk for sip@ietf.org; Wed, 01 Nov 2006 08:52:48 -0500 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 01 Nov 2006 05:52:41 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kA1Do5vV021001; Wed, 1 Nov 2006 05:50:05 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kA1DqQPF021654; Wed, 1 Nov 2006 05:52:27 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 05:52:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 05:52:26 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D221412A8@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Thread-Index: Acb9rN6h7SN1B3yaQXqhgdFqdwYlBgADYTMg From: "Henry Sinnreich" To: "Avshalom Houri" , X-OriginalArrivalTime: 01 Nov 2006 13:52:26.0873 (UTC) FILETIME=[F7253E90:01C6FDBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 182294e3fdac3aef093c0503b87ed133 Cc: p2p-sip@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0580718802==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0580718802== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FDBC.F6B33B54" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FDBC.F6B33B54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Avshalom Houri writes: =20 >Other then a secure channel or S/MIME I do not think that it will be=20 >possible to send a SIP message and get real assurance that the message=20 >will be sent securely in every hop. =20 As you correctly conclude, P2P SIP has the opportunity to finally make SIP secure. =20 Thanks, Henry =20 ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Wednesday, November 01, 2006 5:55 AM To: sip@ietf.org Subject: Re: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) =20 Seems that we need a mechanism to create a trusted "channel" between=20 endpoints that goes through all the intermediaries. The channel should=20 verifiable as secure between the endpoints. After the channel is created then the SIP signalling can go securely over the channel.=20 The protocol for creating such a channel may be SIP based on=20 external to SIP and after we have such a mechanism we can decide if we=20 will use SIPS for messages that need to go over the secure channel=20 or we will use new URI type (e.g. SSIP) or just use some=20 header in the SIP message.=20 The other alternative is the usage of S/MIME which has its drawbacks as=20 we can see in another thread.=20 Other then a secure channel or S/MIME I do not think that it will be=20 possible to send a SIP message and get real assurance that the message=20 will be sent securely in every hop.=20 --Avshalom=20 Dean Willis =20 31/10/2006 18:51=20 To Michael Thomas =20 cc "Joel M. Halpern" , "'IETF SIP List'" , Juha Heinanen , "Elwell, John" =20 Subject Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) =20 =20 =20 On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: > My advise to the working group is to just start over from first =20 > principles as if > SIPS didn't even exist -- which in reality it doesn't. We need to =20 > be thinking > about these things for the long term, and if it's not baked it's =20 > not baked. There > have been many drafts that have lingered on and completely =20 > overhauled over > the years. Why SIPS is treated so differently in that respect is =20 > somewhat > mystifying because dealing with security for SIP is a genuinely =20 > hard problem. > It shouldn't be rushed, and it deserves better than a kludgey =20 > security patina > airbrushed in to get past the IESG. I'm very tempted to endorse this, but I think you're missing one thing. Flimsy as it is, I believe that sips: is as strong as the rest of the =20 current SIP security model since it depends on the same trust =20 assumptions. We can't just restart on sips: without restarting from those =20 fundamental trust assumptions. This is not trivial. Many people would argue that it would turn SIP =20 into a fundamentally different protocol. I think it needs to be done, =20 but I also think we need to clearly document how the current trust =20 model (including sips:) works, because that's what's going to be =20 deployed in the real world for a relatively long time. The P2PSIP work is having to re-examine those fundamental trust =20 assumptions. My current hope is we can do some work there that can be =20 "ported back" into SIP. -- 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 ------_=_NextPart_001_01C6FDBC.F6B33B54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Avshalom Houri writes:

 

>Other then a secure channel or S/MIME I = do not think that it will be

>possible to send a = SIP message and get real assurance that the = message
>will be sent securely in every = hop.

 

As you correctly conclude, P2P = SIP has the opportunity to finally make = SIP secure.

 

Thanks, Henry

 

From: = Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, November = 01, 2006 5:55 AM
To: sip@ietf.org
Subject: Re: What = consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS = meaning))

 


Seems that we need a mechanism to create a = trusted "channel" between
endpoints that goes through all the intermediaries. The channel = should
verifiable as secure between the endpoints. After the channel is = created
then the SIP signalling can go = securely over the channel.

The protocol for creating such a channel may be SIP based on
external to SIP and after we have = such a mechanism we can decide if we
will use SIPS for messages that = need to go over the secure channel
or we will use new URI type (e.g. SSIP) or just use some
header in the SIP = message.

The other alternative is the usage of S/MIME which has its drawbacks = as
we can see in another thread.

Other then a secure channel or S/MIME I do not think that it will = be
possible to send a SIP message and = get real assurance that the message
will be sent securely in every hop.

--Avshalom


Dean = Willis = <dean.willis@softarmor.com> =

31/10/2006 18:51

To

Michael Thomas = <mat@cisco.com>

cc

"Joel = M. Halpern" <joel@stevecrocker.com>, = "'IETF SIP List'" <sip@ietf.org>, = Juha Heinanen <jh@tutpro.com>, "Elwell, John" <john.elwell@siemens.com>

Subject

Re: What consensus? (was: What = controls the lock icon? (Was RE: [Sip]        RE: TLS = meaning))

 

 

 





On Oct 31, 2006, at 8:47 AM, Michael = Thomas wrote:

> My advise to the working group is to = just start over from first  
> principles as if
> SIPS didn't even exist -- which in reality it doesn't. We need to =  
> be thinking
> about these things for the long = term, and if it's not baked it's  
> not baked. There
> have been many drafts that have = lingered on and completely  
> overhauled over
> the years. Why SIPS is treated so differently in that respect is  
> somewhat
> mystifying because dealing with = security for SIP is a genuinely  
> hard problem.
> It shouldn't be rushed, and it = deserves better than a kludgey  
> security patina
> airbrushed in to get past the = IESG.

I'm very tempted to endorse this, but I = think you're missing one thing.

Flimsy as it is, I believe that sips: is = as strong as the rest of the  
current SIP security model since it depends on the same trust  
assumptions.

We can't just restart on sips: without = restarting from those  
fundamental trust = assumptions.

This is not trivial. Many people would = argue that it would turn SIP =  
into a fundamentally different protocol. = I think it needs to be done,  
but I also think we need to clearly = document how the current trust  
model (including sips:) works, because = that's what's going to be  
deployed in the real world for a = relatively long time.

The P2PSIP work is having to re-examine those fundamental trust =  
assumptions. My current hope is we can do = some work there that can be  
"ported back" into = SIP.

--
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

------_=_NextPart_001_01C6FDBC.F6B33B54-- --===============0580718802== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0580718802==-- From sip-bounces@ietf.org Wed Nov 01 09:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGof-0006NR-PJ; Wed, 01 Nov 2006 09:11:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGoe-0006NK-U2 for sip@ietf.org; Wed, 01 Nov 2006 09:11:40 -0500 Received: from [217.19.16.130] (helo=gollum.cambrium.nl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfGoa-0005j7-Eq for sip@ietf.org; Wed, 01 Nov 2006 09:11:40 -0500 Received: (qmail 22648 invoked from network); 1 Nov 2006 14:11:24 -0000 Received: from 82-197-192-189.dsl.cambrium.nl (HELO main) (82.197.192.189) by gollum.cambrium.nl with SMTP; 1 Nov 2006 14:11:24 -0000 From: "Arnoud van Wijk" To: Date: Wed, 1 Nov 2006 15:11:35 +0100 Message-ID: <000901c6fdbf$a3f04050$2500a8c0@main> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9v6O+aQLtmZNoTrqcoFN9DK/5ag== X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Sip] SIP Compatible modems/routers? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0308846926==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0308846926== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C6FDC8.05B4A850" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C6FDC8.05B4A850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am getting this question more and more. Right at home I am using the IX67 from Intertex. But are there other SIP compatible modems or is Intertex still the only one on this planet? Such routers/modems must allow end to end SIP. In the LAN and the WAN. And just SIP to a voice port for analog telephony connection does not count. Arnoud A. T. van Wijk AnnieS New Technology www.AnnieS.nl Mobile textphone (SIP): arnoud@annies.nl ------=_NextPart_000_000A_01C6FDC8.05B4A850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am getting this question more and more. Right at = home I am using the IX67 from Intertex.

But are there other SIP compatible modems or is = Intertex still the only one on this planet?

 

Such routers/modems must allow end to end SIP. In the = LAN and the WAN. And just SIP to a voice port for analog telephony = connection does not count.

 

Arnoud A. T. van Wijk
AnnieS New = Technology
www.AnnieS.nl
Mobile textphone (SIP): arnoud@annies.nl

 

------=_NextPart_000_000A_01C6FDC8.05B4A850-- --===============0308846926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0308846926==-- From sip-bounces@ietf.org Wed Nov 01 09:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHUh-0004qA-Vr; Wed, 01 Nov 2006 09:55:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHUf-0004po-FA for sip@ietf.org; Wed, 01 Nov 2006 09:55:06 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHUb-0007AG-V3 for sip@ietf.org; Wed, 01 Nov 2006 09:55:05 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfHUo-0000pp-Tf; Wed, 01 Nov 2006 08:55:15 -0600 From: "Brian Rosen" To: "'Francois Audet'" , "'Dean Willis'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 09:54:54 -0500 Message-ID: <003201c6fdc5$b2f2d080$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb9LL36RLfxUvULTSqhQXWfR7hYfAAA1/vQACVbrxA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE786D@zrc2hxm0.corp.nortel.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org While I have some reservations on allowing any mechanisms to substitute for TLS, I too am happy with your proposal. Brian > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, October 31, 2006 4:12 PM > To: Dean Willis > Cc: IETF SIP List > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > I'm happy with your proposal, as per your clarification. > > I guess it would mean a new BCP document (plus some changes > to my draft for some sips-related aspects). > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, October 31, 2006 12:40 PM > > To: Audet, Francois (SC100:3055) > > Cc: IETF SIP List > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > > > > On Oct 31, 2006, at 1:08 PM, Francois Audet wrote: > > > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> Sent: Tuesday, October 31, 2006 10:21 AM > > >> To: IETF SIP List > > >> Subject: [Sip] A sips: trial balloon for you to shoot down > > >> > > >> > > >> Ok, let me make a proposal, or perhaps remake one somebody > > else has > > >> made. I've lost track of who said what... > > >> > > >> I think we're now talking about a BCP for secure operations. > > >> > > >> 1) Implementations of SIP SHOULD use TLS as described in RFC > > >> 3261 for all SIP traffic, including traffic using a sip: > > URI scheme. > > >> Failure to use TLS may result in disclosure of sensitive signaling > > >> information to third parties. As a matter of local policy, some > > >> deployments MAY use IPSEC or physically protected infrastructure > > >> instead of TLS on specific links. > > >> Examples where this might be appropriate include persistent IPSEC > > >> relationships between proxies within an operational domain and > > >> physically protected "private network" cables between a TLS > > >> concentrator and the device it is fronting for. > > >> Where TLS is not used, the implementor MUST exercise a > > high level of > > >> caution to provide adequate security and MUST preserve > > operationally > > >> equivalent protection of message integrity, privacy, and > > participant > > >> identity (authentication). > > > > > > That first recommendation seems to be completely independent from > > > SIPS, right? Seems reasonable to me. That sounds like > > BCP-material for > > > sure. Something for a new document. > > > > > >> 2) When using the sips: URI scheme, implementations MUST > > NOT exercise > > >> the "last hop exception" for sips: processing described in > > RFC 3261. > > >> Most scenarios where this technique might have seemed > > appropriate can > > >> be better satisfied using a client-initiated TLS connection as > > >> described in draft-ietf-sip-outbound. User agents that do not > > >> implement both TLS and either terminate TLS connections or > > exercise > > >> draft-ietf-sip-outbound with a US-originated TOS connection to an > > >> outbound will therefore not be able to exercise the sips: > > URI scheme. > > >> Failure to observe this requirement is likely to result in a > > >> reduction of operational security below that expected from > > the sips: > > >> URI scheme. > > > > > > I like the idea of deprecating the last-hop exception. My makes the > > > exact same case your are making here (but it falls short of > > > deprecating the last-hop exception, because, the chair has > > instructed > > > me to not make normative changes). I'm assuming that making a > > > normative change to RFC 3261 for this would require a new document. > > > > I'd argue that making a normative statement about how to best USE > > 3261 is not the same as making a normative change to 3261. > > Thus, this sort of behavioral requirement can be made in a > > BCP, without it actually changing 3261 or being a > > standards-track document. > > > > > > > > What is not clear from this is if there are any > > relationship with your > > > proposal (1). Specifically, I believe that most people > > believe that > > > sips does imply TLS (and does not allow for IPsec). Are you > > proposing > > > to change this so that (1) applies to sips as well? > > > > Nope. 1 is all about sip:. It is there to make sure that you > > get the best possible security if you don't use sips:, > > thereby allowing you to use sips: only when you want to make > > the call to fail if TLS is not present on EVERY hop. > > > > > >> 3) Since some user-agents will not be able to exercise the sips: > > >> scheme, implementations MUST anticipate the failure of sips: > > >> requests and in general SHOULD use sips: only when it is > > desired that > > >> the request will not complete unless TLS will be used on each hop. > > >> Since requests using the sip: URI scheme are (by > > requirement 1 above) > > >> expected to be as securely processed as the implementation > > is able to > > >> do, it is not suggested that one first try sips: and then > > back off to > > >> sip:. > > >> In other words, if you're willing to settle for the best security > > >> that can actually be provided, simply originate the request with a > > >> sip: URI scheme. > > > > > > That is already covered in my draft (and in RFC 3261). > > > No need to do anything else about it. > > > > > > > No, this really say "Don't use sips: as your default > > mechanism. Only use it when you REALLY REALLY want the call > > to fail if EVERY link, including the last hop, is not TLS." > > Again, it;s not a change the the specification of 3261 -- > > it's a guideline on how to best use it. > > Behaviour needs reinforcing from time to time. > > > > > > >> 4) User agent servers that terminate a request using the > > >> sips: URI scheme MUST create any dependent requests using the > > >> sips: URI scheme. > > >> This preserves the commitments of the sips: scheme, and failure to > > >> observe this constraint would give the appearance of sips: > > security > > >> where no such security exists. For example, this requirement means > > >> that that back-to-back user agents bridging two sips: requests use > > >> sips: on both sides. Furthermore, gateways to other protocols not > > >> offering equally strong protections MUST NOT exercise the > > >> sips: URI scheme. In particular, PSTN gateways MUST NOT use sips:, > > >> since the PSTN itself does not offer equivalent > > protections and there > > >> is no ability to determine whether the PSTN segment might be > > >> converted back to a sip: request somewhere downstream. > > > > > > I think this is likely to be somewhat controversial (the > > pstn gateway > > > limitation in particular). > > > > > > > See discussion elsewhere -- without this requirement, sips: > > is exactly the same wishful thinking that sip: is (ok, do > > your best . . .) and might as well be deprecated. > > > > -- > > 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 sip-bounces@ietf.org Wed Nov 01 10:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHb1-0000XU-LE; Wed, 01 Nov 2006 10:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHaz-0000XK-Ig for sip@ietf.org; Wed, 01 Nov 2006 10:01:37 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHay-0008SI-BV for sip@ietf.org; Wed, 01 Nov 2006 10:01:37 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfHbB-0005Lg-MC; Wed, 01 Nov 2006 09:01:50 -0600 From: "Brian Rosen" To: "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 10:01:29 -0500 Message-ID: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SA= In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E024780CA@xmb-rtp-215.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Don't like the PSTN gateway limitation. As was mentioned in an earlier > email, if signaling reaches PSTN gateway, it has reached UAS. Let me relate this to another offshoot of this discussion: when do you get the lock icon? Ignore, just for now, implication on the media channel. Is there ANY possibility of getting a lock icon on any system using the current PSTN or commercial PBX? I think the only answer possible is "yes, use a STU" (a secure telephone that can operate over an ISDN connection). In no other circumstance would anyone consider PSTN or PBX systems to be secure enough to get a lock icon. Therefore, I think that if a part of the call traverse a PSTN or PBX leg, it is not secured signaling, and sips should fail. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 10:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHbk-00015O-0b; Wed, 01 Nov 2006 10:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHbi-00014x-W0 for sip@ietf.org; Wed, 01 Nov 2006 10:02:22 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHbd-00007Z-JO for sip@ietf.org; Wed, 01 Nov 2006 10:02:22 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A6E606E8; Wed, 01 Nov 2006 10:01:58 -0500 From: "Hadriel Kaplan" To: "'Avshalom Houri'" , Subject: RE: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 10:01:58 -0500 Message-ID: <023301c6fdc6$adb1cb20$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb9rJhrH9P5zrqPQ2ayIRFEzRu8nQAGXhdQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think what you're talking about is SIPSEC, the draft Dean mentioned earlier. Good luck with that. ;) -hadriel ------------------------------------------------------ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: Wednesday, November 01, 2006 6:55 AM To: sip@ietf.org Subject: Re: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Seems that we need a mechanism to create a trusted "channel" between endpoints that goes through all the intermediaries. The channel should verifiable as secure between the endpoints. After the channel is created then the SIP signalling can go securely over the channel. The protocol for creating such a channel may be SIP based on external to SIP and after we have such a mechanism we can decide if we will use SIPS for messages that need to go over the secure channel or we will use new URI type (e.g. SSIP) or just use some header in the SIP message. The other alternative is the usage of S/MIME which has its drawbacks as we can see in another thread. Other then a secure channel or S/MIME I do not think that it will be possible to send a SIP message and get real assurance that the message will be sent securely in every hop. --Avshalom _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 10:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfI0R-0004W5-8J; Wed, 01 Nov 2006 10:27:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfI0Q-0004Vx-0V for sip@ietf.org; Wed, 01 Nov 2006 10:27:54 -0500 Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfI0L-0008Fv-MO for sip@ietf.org; Wed, 01 Nov 2006 10:27:53 -0500 Received: from eng.infointeractive.com ([10.142.0.50]:45945 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S362135AbWKAP1k (ORCPT ); Wed, 1 Nov 2006 11:27:40 -0400 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <6061-514>; Wed, 1 Nov 2006 11:27:37 -0400 Date: Wed, 1 Nov 2006 11:27:37 -0400 From: David Benoit To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] A sips: trial balloon for you to shoot down Message-ID: <20061101152737.GB10111@infointeractive.com> References: <8983EC086A9D954BA74D9763E853CF3E024780CA@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E024780CA@xmb-rtp-215.amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, Oct 31, 2006 at 02:00:51PM -0500, Sanjay Sinha (sanjsinh) wrote: > Don't like the PSTN gateway limitation. As was mentioned in an earlier > email, if signaling reaches PSTN gateway, it has reached UAS. I think you mean UAC. As far as SIP is concerned, the gateway is the client. David -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 10:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGS-0005Fv-2e; Wed, 01 Nov 2006 10:44:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGQ-0005FD-O7 for sip@ietf.org; Wed, 01 Nov 2006 10:44:26 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIA7-0002bL-R3 for sip@ietf.org; Wed, 01 Nov 2006 10:37:57 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2006 07:37:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Fbtce030994; Wed, 1 Nov 2006 07:37:55 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1FbtW4018399; Wed, 1 Nov 2006 07:37:55 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn2-580.cisco.com [10.21.114.68]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA1FP3e4013878; Wed, 1 Nov 2006 07:25:03 -0800 Message-ID: <4548BF56.3020006@cisco.com> Date: Wed, 01 Nov 2006 07:37:58 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> In-Reply-To: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1250; t=1162395475; x=1163259475; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DfUTxn6IgjLQQzti8C+nkZkpuBz4=3D; b=L5sTSRe4flVA1QBWbu0j1GDADIDXmoSap4m/4W+ZDeON7aCLLPG5ya0hx79vMx7UNG0SQ1s+ X3PJz8/i0W9EJs5EJAjLCggDJWzF+9bRdXYpLvSTpMo64kC82KjtF0XX; X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'IETF SIP List' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: >>Don't like the PSTN gateway limitation. As was mentioned in an earlier >>email, if signaling reaches PSTN gateway, it has reached UAS. >> >> > >Let me relate this to another offshoot of this discussion: when do you get >the lock icon? Ignore, just for now, implication on the media channel. > >Is there ANY possibility of getting a lock icon on any system using the >current PSTN or commercial PBX? > >I think the only answer possible is "yes, use a STU" (a secure telephone >that can operate over an ISDN connection). In no other circumstance would >anyone consider PSTN or PBX systems to be secure enough to get a lock icon. > >Therefore, I think that if a part of the call traverse a PSTN or PBX leg, it >is not secured signaling, and sips should fail. > > Wow, that's a pretty slippery slope -- my home phone doesn't encrypt the ringer bits before it hits my ear... sounds like by this definition, the call should fail there too. What strikes me about this is that there are different answers to all of this depending on context. Which is why trying to encode all this into one "S" bit in an URI scheme is hopeless. Bits are cheap; let them be fruitful and multiply. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 11:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIVc-0000Ee-Uj; Wed, 01 Nov 2006 11:00:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIVa-0000EQ-Tb for sip@ietf.org; Wed, 01 Nov 2006 11:00:06 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIVW-00012x-4O for sip@ietf.org; Wed, 01 Nov 2006 11:00:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 16:00:01 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3629@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down thread-index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMA== From: "Attila Sipos" To: "Brian Rosen" , "Sanjay Sinha (sanjsinh)" , "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Therefore, I think that if a part of the call traverse a=20 >> PSTN or PBX leg, it >> is not secured signaling, and sips should fail. >>=20 Imagine a system where you have PBX and an ISDN/SIP gateway. The office which uses the PBX want to be able make secure SIP calls to the global internet. So, if, as is said, "sips should fail", then these users won't be able to use sips. I don't think it is right to take sips ability away from these users. I mean, you could have the PBX in a secured room. Wouldn't that be secure enough? And how does one define "secured signaling" anyway? And there's nothing to stop anyone getting a SIPS phone and interfacing it to something which is "insecure". In my opinion, whether to allow SIPS must be decided by the administrator and not nailed down in a standard. regards, Attila _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 11:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIuE-0003S3-9s; Wed, 01 Nov 2006 11:25:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIuC-0003Jm-8F for sip@ietf.org; Wed, 01 Nov 2006 11:25:32 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIjA-0004kB-99 for sip@ietf.org; Wed, 01 Nov 2006 11:14:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfIjJ-0002gM-37; Wed, 01 Nov 2006 10:14:17 -0600 From: "Brian Rosen" To: "'Attila Sipos'" , "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 11:13:57 -0500 Message-ID: <006101c6fdd0$bdd251a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMAAAo5Pw In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0012A3629@veg-brk-svr-pri.vegastream> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Clearly, we don't agree. I would say that the PBX can't provide security to any other call, how could it possibly provide security to a sips call? One end is insecure. Dean has a proposed wording for what we mean, and I'm happy with that. PSTN (or PBX) doesn't do that. There are no protocol police, so of course you are correct that anyone can break the rules and get away with it. We have standards to define what things mean, and this is an example of needing such a definition. I think we all agree that sips is not the only thing we need for signaling security, and many of the ideas that have been discussed for further work beyond sips (and S/MIME) have the notion that there is not a black/white setting, one end should express it's desired security properties, and have a way to determine if those properties have been met. I like those thoughts, will contribute to the development of such a mechanism, and think it will address your concerns. That's not sips. Brian > -----Original Message----- > From: Attila Sipos [mailto:Attila.Sipos@vegastream.com] > Sent: Wednesday, November 01, 2006 11:00 AM > To: Brian Rosen; Sanjay Sinha (sanjsinh); Dean Willis; IETF SIP List > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > >> Therefore, I think that if a part of the call traverse a > >> PSTN or PBX leg, it > >> is not secured signaling, and sips should fail. > >> > > Imagine a system where you have PBX and an ISDN/SIP > gateway. The office which uses the PBX want to be able > make secure SIP calls to the global internet. > > So, if, as is said, "sips should fail", then these > users won't be able to use sips. > > I don't think it is right to take sips ability away from > these users. I mean, you could have the PBX in a secured room. > Wouldn't that be secure enough? > > And how does one define "secured signaling" anyway? And there's > nothing to stop anyone getting a SIPS phone and interfacing > it to something which is "insecure". > > In my opinion, whether to allow SIPS must be decided by > the administrator and not nailed down in a standard. > > regards, > > Attila > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 11:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIzR-0007aF-Ic; Wed, 01 Nov 2006 11:30:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIzP-0007Zv-Lq for sip@ietf.org; Wed, 01 Nov 2006 11:30:55 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIzL-0003dx-1g for sip@ietf.org; Wed, 01 Nov 2006 11:30:55 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id ABA003B4; Wed, 01 Nov 2006 11:30:24 -0500 From: "Hadriel Kaplan" To: "'Brian Rosen'" , "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 11:30:24 -0500 Message-ID: <027901c6fdd3$0876ad80$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAsMboA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That isn't even the case in https. When you connect to an https server, you have no idea how the back-end gets/stores/updates its info. It could be creating the page by pulling from another server using tftp as far as you know. If that https server gets/sends emails using the contents of a post/get https message, it says nothing about how the emails you read got to that server, or how emails you tell it to send are sent. Despite that your https post message caused an email to be sent (if it worked that way), the web server is under no obligation to refuse to send the email, or break your https connection, just because it sends them using smtp unsecured. -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, November 01, 2006 10:01 AM > To: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > Don't like the PSTN gateway limitation. As was mentioned in an earlier > > email, if signaling reaches PSTN gateway, it has reached UAS. > > Let me relate this to another offshoot of this discussion: when do you get > the lock icon? Ignore, just for now, implication on the media channel. > > Is there ANY possibility of getting a lock icon on any system using the > current PSTN or commercial PBX? > > I think the only answer possible is "yes, use a STU" (a secure telephone > that can operate over an ISDN connection). In no other circumstance would > anyone consider PSTN or PBX systems to be secure enough to get a lock icon. > > Therefore, I think that if a part of the call traverse a PSTN or PBX leg, > it > is not secured signaling, and sips should fail. > > Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 11:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJ36-0004dz-Hv; Wed, 01 Nov 2006 11:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJ35-0004cj-S8 for sip@ietf.org; Wed, 01 Nov 2006 11:34:43 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJ32-00077X-Gc for sip@ietf.org; Wed, 01 Nov 2006 11:34:43 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1GYZv09995; Wed, 1 Nov 2006 11:34:35 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 10:34:32 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> In-Reply-To: <4276CFA4-4BEB-4E84-ADBC-CB74B735D933@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9d0l82MLqZOJhT4KNxZO6BS01cwAV81gg From: "Francois Audet" To: "Dean Willis" , "Sanjay Sinha \(\(sanjsinh\)\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is a difference however between and SBC and PSTN Gateway, in that their security model are quite different. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 31, 2006 9:23 PM > To: Sanjay Sinha ((sanjsinh)) > Cc: IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 > On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote: >=20 > > > > It is my understanding is that SBC is esentially a B2BUA or=20 > an IP-IP=20 > > gateway, if one leg is SIP and another one is say,=20 > H323/MGCP. A pstn=20 > > gateway is termination point of IP leg signaling. It will have fxs/=20 > > pots or a PBX interface on the other leg. So I can have an IAD with=20 > > pots phones hanging off of fxs port in a small branch=20 > office and know=20 > > that interface is secure/trusted. > > >=20 > Ok, that's fair. I wouldn't describe that as a PSTN Gateway=20 > so much as I would describe it as a multi-user UA that uses=20 > telephone handsets to implement its user interface devices.=20 > By the same token, it would be OK to run sips: to a Mac that=20 > uses a Bluetooth headset, even though Bluetooth isn't TLS. >=20 > By PSTN gateway, I mean a box that converts the SIP call into=20 > a signaled call on a PSTN line (especially a "trunk" line). >=20 > Of course, once you stick an fxo line on that multiuser-UA=20 > box and start pumping calls back into the P (that's Public)=20 > STN, you have a security problem again. This could easily=20 > happen with a PBX, so that could be a problem. It might be=20 > legit to say that a PBX simply can't do sips:, because it=20 > can't meet the security assurances of sips:. >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 11:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJKr-0008Mm-8r; Wed, 01 Nov 2006 11:53:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJKp-0008Mh-Qv for sip@ietf.org; Wed, 01 Nov 2006 11:53:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJKn-00013m-9l for sip@ietf.org; Wed, 01 Nov 2006 11:53:03 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2006 08:53:00 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Gr07a018102; Wed, 1 Nov 2006 08:53:00 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA1GqdbZ003332; Wed, 1 Nov 2006 08:52:56 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 11:52:50 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 11:52:50 -0500 Message-ID: <4548D0E1.2000904@cisco.com> Date: Wed, 01 Nov 2006 11:52:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> In-Reply-To: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 16:52:50.0241 (UTC) FILETIME=[2A602310:01C6FDD6] DKIM-Signature: a=rsa-sha1; q=dns; l=3218; t=1162399980; x=1163263980; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=k5z9mJ85sPHmcTUnKd09hykZ4xcrdPeCVdOY4AULRVpNU2PskZ0XIrSKZwF2w9xpd9LtgveU c7sp/K8s7yxmpJt4umN/K0jHltzfp+fHLxs/95A6VxWGSuhKUXAEiAeT; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'IETF SIP List' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, While I understand your point, and agree with it for the most part, I am having trouble turning it into a concrete set of rules. In general, there are lots of things that can happen to the call signaling info, and the media, once it reaches the UAC or UAS. There is no guarantee that it is ever secure, regardless of the security of the link between the UAC and UAS: - info can be displayed on a public display that can be viewed by parties other than the user of the device - audio can be played in a way that can be heard by others - some or all aspects of the session may be relayed to a peripheral device of the UA, e.g. a bluetooth headset, that is not secured and can be intercepted by others. - the user of the UA may let someone else operate the device. A PSTN GW is in effect no different than the bluetooth headset in this regard. Why should we allow one and not the other? I think the most one can hope for is that the identity of the remote UA is known, and that the caller trusts the UA and its user to properly handle the information conveyed in the call. When calling a phone number (e.g. +12125551234), the kinds of credentials that are available are somewhat dubious. I don't think we have any form of credential that actually states "I hold the responsibility for +12125551234". At best I think we may have something that says: "I have responsibility for sip:+12125551234@provider.com". If that happens to come from the operator of a gateway, then what it says about what happens on the other side of the gw is not clear - perhaps nothing. Operationally, this might mean that if I was trying to call sip:+12125551234@provider.com, and I receive credentials for that back, and the path between us is secure, then I might consider the call secure. But if I was calling tel:+12125551234 and I receive back credentials for sip:+12125551234@provider.com then I might be wise not to consider this secure. That leaves the problem of whether there is ever a way to receive credentials for tel:+12125551234. Paul Brian Rosen wrote: >> Don't like the PSTN gateway limitation. As was mentioned in an earlier >> email, if signaling reaches PSTN gateway, it has reached UAS. > > Let me relate this to another offshoot of this discussion: when do you get > the lock icon? Ignore, just for now, implication on the media channel. > > Is there ANY possibility of getting a lock icon on any system using the > current PSTN or commercial PBX? > > I think the only answer possible is "yes, use a STU" (a secure telephone > that can operate over an ISDN connection). In no other circumstance would > anyone consider PSTN or PBX systems to be secure enough to get a lock icon. > > Therefore, I think that if a part of the call traverse a PSTN or PBX leg, it > is not secured signaling, and sips should fail. > > Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 11:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJOa-0002I9-Ho; Wed, 01 Nov 2006 11:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJOW-0002H6-Dl for sip@ietf.org; Wed, 01 Nov 2006 11:56:52 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJOV-0002o3-6n for sip@ietf.org; Wed, 01 Nov 2006 11:56:52 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A1CE02E4; Wed, 01 Nov 2006 11:56:46 -0500 From: "Hadriel Kaplan" To: "'Brian Rosen'" , "'Attila Sipos'" , "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 11:56:46 -0500 Message-ID: <028001c6fdd6$b719ae20$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMAAAo5PwAADXtVA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <006101c6fdd0$bdd251a0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, November 01, 2006 11:14 AM > > Clearly, we don't agree. > > I would say that the PBX can't provide security to any other call, how > could > it possibly provide security to a sips call? One end is insecure. It did provide security for a sips session. That session is between the UAC and the sips UAS. The UAS is the end, as far as sip/sips is concerned. Are you suggesting sips is more than a specific uri scheme for SIP, and somehow a cross-protocol, universal fiat, based on an ambiguous definition of "secure"? :) Will the BCP start listing all device types and roles, and whether they are allowed to accept a sips request or not? A Bluetooth handset is allowed to, a home cablemodem (IAD) with an FXO interface is allowed to, but if that IAD is classified as a PBX then not. Unless that "PBX" is an open-source app in my house PC. But if my PC gets moved, then it needs to stop accepting sips. This would be like classifying pornography. "I know it when I see it." -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 12:08:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJWQ-0007dZ-RE; Wed, 01 Nov 2006 12:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJWN-0007bN-OH for sip@ietf.org; Wed, 01 Nov 2006 12:05:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJWL-0005qZ-Af for sip@ietf.org; Wed, 01 Nov 2006 12:04:59 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2006 09:04:56 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1H4sWG025549; Wed, 1 Nov 2006 09:04:54 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA1H3ibn009887; Wed, 1 Nov 2006 09:04:54 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:04:32 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:04:32 -0500 Message-ID: <4548D39F.8050905@cisco.com> Date: Wed, 01 Nov 2006 12:04:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 17:04:32.0274 (UTC) FILETIME=[CCD1DF20:01C6FDD7] DKIM-Signature: a=rsa-sha1; q=dns; l=2952; t=1162400694; x=1163264694; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=n5JtDMDPmHeOZFWkIN73/ksn2dgr5rp2h/L25qqjY+Ss+oZjpH3E+WOF6IKZ+Gbg8qqTzB3R NGRYd1/KROvOjFbZOberCEAZZ2MNuJ4y1yTrCTr/n9ucwzOWPUMyDEcj; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > There is a difference however between and SBC and PSTN Gateway, in that > their security model are quite different. I don't see the difference. In either case, the call has reached a UA. From that point on you are trusting that the UA will do the right thing. The best you can do is determine the identity of that UA and decide if it is one you wish to trust. If you have phone service from a provider that uses SBCs at its connection to the internet, when I call "you" I am really calling that SBC. All security and authentication properties are with it, not you or your devices. I must trust it. The same is true if I call a gateway. Paul >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Tuesday, October 31, 2006 9:23 PM >> To: Sanjay Sinha ((sanjsinh)) >> Cc: IETF SIP List >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >> >> >> On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote: >> >>> It is my understanding is that SBC is esentially a B2BUA or >> an IP-IP >>> gateway, if one leg is SIP and another one is say, >> H323/MGCP. A pstn >>> gateway is termination point of IP leg signaling. It will have fxs/ >>> pots or a PBX interface on the other leg. So I can have an IAD with >>> pots phones hanging off of fxs port in a small branch >> office and know >>> that interface is secure/trusted. >>> >> Ok, that's fair. I wouldn't describe that as a PSTN Gateway >> so much as I would describe it as a multi-user UA that uses >> telephone handsets to implement its user interface devices. >> By the same token, it would be OK to run sips: to a Mac that >> uses a Bluetooth headset, even though Bluetooth isn't TLS. >> >> By PSTN gateway, I mean a box that converts the SIP call into >> a signaled call on a PSTN line (especially a "trunk" line). >> >> Of course, once you stick an fxo line on that multiuser-UA >> box and start pumping calls back into the P (that's Public) >> STN, you have a security problem again. This could easily >> happen with a PBX, so that could be a problem. It might be >> legit to say that a PBX simply can't do sips:, because it >> can't meet the security assurances of sips:. >> >> -- >> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 12:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJdR-0003DF-7o; Wed, 01 Nov 2006 12:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJdP-0003Cr-Pj for sip@ietf.org; Wed, 01 Nov 2006 12:12:15 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJdM-0003g9-LM for sip@ietf.org; Wed, 01 Nov 2006 12:12:15 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA1H5Kh23037; Wed, 1 Nov 2006 12:05:20 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Wed, 1 Nov 2006 11:12:08 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE8200@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D85A8@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb9olPOWo8yJiBwR4G8jpHrE3MyfQANkrDQ From: "Francois Audet" To: "Elwell, John" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > > There are cases where you want signalling to be secure (for=20 > > authentication, impersonation, theft of service, etc.), but=20 > you don't=20 > > need, or want, or even can have encrypted media. > [JRE] No, but you might want authenticated media. It is all=20 > very well saying that the signalling comes from the person=20 > you think it comes from, but if the media is coming from=20 > somewhere else, that doesn't help the average user. Sure, but it's a different problem. Media security and Signalling security are two different things. SIPS is strictly about hop-by-hop signalling security with TLS.=20 That's why sips !=3D padlock item, otherwise, you'll give a false sense = of security to the "average user". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 12:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJes-0004Ku-Ix; Wed, 01 Nov 2006 12:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJeq-0004Js-SP for sip@ietf.org; Wed, 01 Nov 2006 12:13:44 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJen-0004NS-5z for sip@ietf.org; Wed, 01 Nov 2006 12:13:42 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA1H6Hh23118; Wed, 1 Nov 2006 12:06:17 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 11:13:04 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE8204@zrc2hxm0.corp.nortel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D221412A8@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Thread-Index: Acb9rN6h7SN1B3yaQXqhgdFqdwYlBgADYTMgAAej3QA= From: "Francois Audet" To: "Henry Sinnreich" , "Avshalom Houri" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Cc: p2p-sip@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1363519278==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1363519278== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FDD8.FEF96D23" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FDD8.FEF96D23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Or at least to move to a different set of security problems. :^) ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, November 01, 2006 5:52 AM To: Avshalom Houri; sip@ietf.org Cc: p2p-sip@cs.columbia.edu Subject: RE: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) =09 =09 Avshalom Houri writes: =20 >Other then a secure channel or S/MIME I do not think that it will be=20 >possible to send a SIP message and get real assurance that the message=20 >will be sent securely in every hop. =20 As you correctly conclude, P2P SIP has the opportunity to finally make SIP secure. =20 Thanks, Henry =20 =09 ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Wednesday, November 01, 2006 5:55 AM To: sip@ietf.org Subject: Re: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) =20 =09 Seems that we need a mechanism to create a trusted "channel" between=20 endpoints that goes through all the intermediaries. The channel should=20 verifiable as secure between the endpoints. After the channel is created=20 then the SIP signalling can go securely over the channel.=20 =09 The protocol for creating such a channel may be SIP based on=20 external to SIP and after we have such a mechanism we can decide if we=20 will use SIPS for messages that need to go over the secure channel=20 or we will use new URI type (e.g. SSIP) or just use some=20 header in the SIP message.=20 =09 The other alternative is the usage of S/MIME which has its drawbacks as=20 we can see in another thread.=20 =09 Other then a secure channel or S/MIME I do not think that it will be=20 possible to send a SIP message and get real assurance that the message=20 will be sent securely in every hop.=20 =09 --Avshalom=20 =09 =09 =09 Dean Willis =20 31/10/2006 18:51=20 To Michael Thomas =20 cc "Joel M. Halpern" , "'IETF SIP List'" , Juha Heinanen , "Elwell, John" =20 Subject Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) =20 =20 =20 =09 =09 =09 =09 On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: =09 > My advise to the working group is to just start over from first =20 > principles as if > SIPS didn't even exist -- which in reality it doesn't. We need to =20 > be thinking > about these things for the long term, and if it's not baked it's =20 > not baked. There > have been many drafts that have lingered on and completely =20 > overhauled over > the years. Why SIPS is treated so differently in that respect is =20 > somewhat > mystifying because dealing with security for SIP is a genuinely =20 > hard problem. > It shouldn't be rushed, and it deserves better than a kludgey > security patina > airbrushed in to get past the IESG. =09 I'm very tempted to endorse this, but I think you're missing one thing. =09 Flimsy as it is, I believe that sips: is as strong as the rest of the =20 current SIP security model since it depends on the same trust =20 assumptions. =09 We can't just restart on sips: without restarting from those =20 fundamental trust assumptions. =09 This is not trivial. Many people would argue that it would turn SIP =20 into a fundamentally different protocol. I think it needs to be done, =20 but I also think we need to clearly document how the current trust =20 model (including sips:) works, because that's what's going to be deployed in the real world for a relatively long time. =09 The P2PSIP work is having to re-examine those fundamental trust assumptions. My current hope is we can do some work there that can be =20 "ported back" into SIP. =09 -- Dean =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C6FDD8.FEF96D23 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Or at least to move to a different set of = security=20 problems. :^)

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Wednesday, November 01, = 2006 5:52=20 AM
To: Avshalom Houri; sip@ietf.org
Cc:=20 p2p-sip@cs.columbia.edu
Subject: RE: What consensus? (was: = What=20 controls the lock icon? (Was RE:[Sip] RE: TLS = meaning))

Avshalom Houri=20 writes:

 

>Other then a = secure=20 channel or S/MIME I do not think that it will be =

>possible to=20 send a SIP message and = get real=20 assurance that the message
>will be sent=20 securely in every hop.

 

As you correctly = conclude,=20 P2P SIP has the = opportunity to=20 finally make SIP=20 secure.

 

Thanks,=20 Henry

 

From:=20 Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, November 01, = 2006 5:55=20 AM
To:=20 sip@ietf.org
Subject: Re:=20 What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: = TLS=20 meaning))

 


Seems that we = need a=20 mechanism to create a trusted "channel" between =
endpoints that = goes=20 through all the intermediaries. The channel should =
verifiable as = secure=20 between the endpoints. After the channel is created =
then the = SIP signalling can go securely over the=20 channel.

The protocol for = creating=20 such a channel may be SIP = based=20 on
external to=20 SIP and after we have = such a=20 mechanism we can decide if we
will use=20 SIPS for messages that = need to go=20 over the secure channel
or we will=20 use new URI type (e.g. SSIP) or=20 just use some
header in the=20 SIP = message.=20

The other = alternative is=20 the usage of S/MIME which has its drawbacks as
we can see in = another=20 thread.

Other then a = secure=20 channel or S/MIME I do not think that it will be =
possible to send = a=20 SIP message and get real = assurance=20 that the message
will be sent = securely in=20 every hop.

--Avshalom=20


Dean=20 Willis=20 <dean.willis@softarmor.com>=20

31/10/2006=20 18:51

To

Michael Thomas=20 <mat@cisco.com> =

cc

"Joel M. Halpern"=20 <joel@stevecrocker.com>, "'IETF SIP List'" = <sip@ietf.org>, Juha=20 Heinanen <jh@tutpro.com>, "Elwell, John"=20 <john.elwell@siemens.com>=20

Subject

Re: = What=20 consensus? (was: What controls the lock icon? (Was RE: = [Sip]=20        RE: TLS=20 = meaning))

 

 

 





On Oct 31, 2006, at 8:47 AM, Michael Thomas=20 wrote:

> My = advise to the=20 working group is to just start over from first =  
> principles as if
> SIPS didn't=20 even exist -- which in reality it doesn't. We need to=20  
> be=20 thinking
> about = these things=20 for the long term, and if it's not baked it's =  
> not baked. There
> have been many drafts that have lingered on = and=20 completely  
> = overhauled=20 over
> the years. Why = SIPS is treated so = differently in=20 that respect is  
>=20 somewhat
> mystifying = because=20 dealing with security for SIP is a=20 genuinely  
> = hard=20 problem.
> It = shouldn't be=20 rushed, and it deserves better than a kludgey =  
> security patina
> airbrushed in to get past the=20 IESG.

I'm very = tempted to=20 endorse this, but I think you're missing one=20 thing.

Flimsy as it = is, I=20 believe that sips: is as strong as the rest of the=20  
current = SIP security model since it depends on = the same=20 trust  
assumptions.

We can't just restart on sips: without restarting = from=20 those  
fundamental = trust=20 assumptions.

This is = not=20 trivial. Many people would argue that it would turn SIP  
into a fundamentally different protocol. I think = it needs=20 to be done,  
but I = also=20 think we need to clearly document how the current trust=20  
model (including = sips:)=20 works, because that's what's going to be =  
deployed in the real world for a relatively long=20 time.

The = P2PSIP work is having to re-examine those = fundamental=20 trust  
assumptions. My=20 current hope is we can do some work there that can be=20  
"ported back" = into=20 SIP.

--
Dean

_______________________________________________
<= FONT=20 face=3D"Courier New">Sip mailing list=20 =  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core=20 SIP=20 Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current=20 sip
Use sipping@ietf.org = for new=20 developments on the application of=20 = sip

------_=_NextPart_001_01C6FDD8.FEF96D23-- --===============1363519278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1363519278==-- From sip-bounces@ietf.org Wed Nov 01 12:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJgA-0005An-89; Wed, 01 Nov 2006 12:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJg8-0005Af-T1 for sip@ietf.org; Wed, 01 Nov 2006 12:15:04 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJg7-00050e-Ch for sip@ietf.org; Wed, 01 Nov 2006 12:15:04 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1HEvv04331; Wed, 1 Nov 2006 12:14:57 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 11:14:54 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE8213@zrc2hxm0.corp.nortel.com> In-Reply-To: <4548BF56.3020006@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9zO+XlH6suB62QTOMSYPcein9zwADEi7w From: "Francois Audet" To: "Michael Thomas" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Sanjay Sinha \(sanjsinh\)" , IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with you on this one. =20 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Wednesday, November 01, 2006 7:38 AM > To: Brian Rosen > Cc: 'Sanjay Sinha (sanjsinh)'; 'IETF SIP List'; 'Dean Willis' > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 > Brian Rosen wrote: >=20 > >>Don't like the PSTN gateway limitation. As was mentioned in=20 > an earlier=20 > >>email, if signaling reaches PSTN gateway, it has reached UAS. > >> =20 > >> > > > >Let me relate this to another offshoot of this discussion:=20 > when do you=20 > >get the lock icon? Ignore, just for now, implication on the=20 > media channel. > > > >Is there ANY possibility of getting a lock icon on any=20 > system using the=20 > >current PSTN or commercial PBX? > > > >I think the only answer possible is "yes, use a STU" (a secure=20 > >telephone that can operate over an ISDN connection). In no other=20 > >circumstance would anyone consider PSTN or PBX systems to be=20 > secure enough to get a lock icon. > > > >Therefore, I think that if a part of the call traverse a PSTN or PBX=20 > >leg, it is not secured signaling, and sips should fail. > > =20 > > > Wow, that's a pretty slippery slope -- my home phone doesn't=20 > encrypt the ringer bits before it hits my ear... sounds like=20 > by this definition, the call should fail there too. >=20 > What strikes me about this is that there are different=20 > answers to all of this depending on context. Which is why=20 > trying to encode all this into one "S" > bit in an URI scheme is hopeless. Bits are cheap; let them be=20 > fruitful and multiply. >=20 > Mike >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 12:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJoN-0008C6-0i; Wed, 01 Nov 2006 12:23:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJoL-00088Z-Jp for sip@ietf.org; Wed, 01 Nov 2006 12:23:33 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJoG-0004vV-Aq for sip@ietf.org; Wed, 01 Nov 2006 12:23:33 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1HNMA10664; Wed, 1 Nov 2006 12:23:22 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 11:23:20 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE8237@zrc2hxm0.corp.nortel.com> In-Reply-To: <4548D39F.8050905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9195+EoUuRenTQueHPLKqg3meYwAAY3bA From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, November 01, 2006 9:05 AM > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; Sanjay Sinha ((sanjsinh)); IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 >=20 > Francois Audet wrote: > > There is a difference however between and SBC and PSTN Gateway, in=20 > > that their security model are quite different. >=20 > I don't see the difference. >=20 > In either case, the call has reached a UA. From that point on=20 > you are trusting that the UA will do the right thing. The=20 > best you can do is determine the identity of that UA and=20 > decide if it is one you wish to trust. The difference is that there is a level of "security" on PSTN. You can't do IP address spoofing for example. You can't tap into a hub.=20 (Yes, I know: there are ways to tap into analog lines too). The point is that for many people, they are happy with the security level provided by the PSTN, but not with the one provided by IP telephony or SIP when there is no TLS/SRTP/whatever. That's my point. So, I can see that, as Michael Thomas said, putting all the "attributes of security" into the letter "s" is not terribly useful. On the specific issue of "is sips allowed" when you leave the "network", I am a bit ambivalent. I think if you are Leaving SIP and going to another IP protocol (say H.323) then we shouldn't allow SIPs. However, for the PSTN case, I'm not sure. I think I'm ok either way. I think arguments on both sides are valid. =20 > If you have phone service from a provider that uses SBCs at=20 > its connection to the internet, when I call "you" I am really=20 > calling that SBC. All security and authentication properties=20 > are with it, not you or your devices. I must trust it. The=20 > same is true if I call a gateway. >=20 > Paul >=20 > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Tuesday, October 31, 2006 9:23 PM > >> To: Sanjay Sinha ((sanjsinh)) > >> Cc: IETF SIP List > >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down > >> > >> > >> On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote: > >> > >>> It is my understanding is that SBC is esentially a B2BUA or > >> an IP-IP > >>> gateway, if one leg is SIP and another one is say, > >> H323/MGCP. A pstn > >>> gateway is termination point of IP leg signaling. It will=20 > have fxs/=20 > >>> pots or a PBX interface on the other leg. So I can have=20 > an IAD with=20 > >>> pots phones hanging off of fxs port in a small branch > >> office and know > >>> that interface is secure/trusted. > >>> > >> Ok, that's fair. I wouldn't describe that as a PSTN=20 > Gateway so much=20 > >> as I would describe it as a multi-user UA that uses telephone=20 > >> handsets to implement its user interface devices. > >> By the same token, it would be OK to run sips: to a Mac=20 > that uses a=20 > >> Bluetooth headset, even though Bluetooth isn't TLS. > >> > >> By PSTN gateway, I mean a box that converts the SIP call into a=20 > >> signaled call on a PSTN line (especially a "trunk" line). > >> > >> Of course, once you stick an fxo line on that multiuser-UA box and=20 > >> start pumping calls back into the P (that's Public) STN,=20 > you have a=20 > >> security problem again. This could easily happen with a=20 > PBX, so that=20 > >> could be a problem. It might be legit to say that a PBX=20 > simply can't=20 > >> do sips:, because it can't meet the security assurances of sips:. > >> > >> -- > >> Dean > >> > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 13:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKwM-0002Fj-4C; Wed, 01 Nov 2006 13:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKwK-0002FD-9m for sip@ietf.org; Wed, 01 Nov 2006 13:35:52 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfKwH-0003iY-T1 for sip@ietf.org; Wed, 01 Nov 2006 13:35:52 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2006 13:35:49 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1IZdTv029439; Wed, 1 Nov 2006 13:35:39 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1IZcDM018939; Wed, 1 Nov 2006 13:35:38 -0500 (EST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:35:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 13:35:28 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E024D2D06@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9y3kOP8mTFSYYT6WFvcIXJOYPpQAGNvrA From: "Sanjay Sinha \(sanjsinh\)" To: "David Benoit" X-OriginalArrivalTime: 01 Nov 2006 18:35:28.0919 (UTC) FILETIME=[813BD270:01C6FDE4] DKIM-Signature: a=rsa-sha1; q=dns; l=1192; t=1162406139; x=1163270139; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:RE=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:=22David=20Benoit=22=20; X=v=3Dcisco.com=3B=20h=3DNF0oaGeXYLvOSL89WNDCSr2Vjxk=3D; b=Ay3OHkcXuxJro3YN4Z+lrpk/VeeP5B6pOVpaoCA+BgPwRLSYk4CPVpu9jI2wtWpFdAFIhyyT Xck1O+Z3oqHLVHGSuHvv1TEGJV5c7h6BPEDEtLy+G0dovfmKhQFfhTnA; Authentication-Results: rtp-dkim-1.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >-----Original Message----- >From: David Benoit [mailto:benoit@infointeractive.com]=20 >Sent: Wednesday, November 01, 2006 10:28 AM >To: Sanjay Sinha (sanjsinh) >Cc: IETF SIP List; Dean Willis >Subject: Re: [Sip] A sips: trial balloon for you to shoot down > >On Tue, Oct 31, 2006 at 02:00:51PM -0500, Sanjay Sinha=20 >(sanjsinh) wrote: >> Don't like the PSTN gateway limitation. As was mentioned in=20 >an earlier=20 >> email, if signaling reaches PSTN gateway, it has reached UAS. > >I think you mean UAC. As far as SIP is concerned, the gateway=20 >is the client. No I meant UAS. For a call originated from a SIP UA to a pstn user, gateway is acting like a UAS. Sanjay. > >David >-- >David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax:=20 >902-832-1015 "Complex problems have simple, neat and wrong=20 >solutions" - H. L. Menken > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 13:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfL4d-0000Wj-R0; Wed, 01 Nov 2006 13:44:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfL4c-0000Wc-39 for sip@ietf.org; Wed, 01 Nov 2006 13:44:26 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfL4Z-0006P3-Nl for sip@ietf.org; Wed, 01 Nov 2006 13:44:26 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfL4k-00041j-4Z; Wed, 01 Nov 2006 12:44:34 -0600 From: "Brian Rosen" To: "'Hadriel Kaplan'" , "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 13:44:15 -0500 Message-ID: <00c301c6fde5$bd0dbc90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAsMboAAFDUVg In-Reply-To: <027901c6fdd3$0876ad80$0500a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.6 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is some interpretation here. The words in a BCP can only be so precise. I think the way Dean phrased it is okay. I understand that any element may be using some protocols to do its job that may involve some sense of security, and inappropriate choices may make the security the endpoints think they are getting not actually be there. I can live with that. I think that we don't consider the PSTN signaling to be "secure". We consider it more secure than open Internet in-the-clear signaling, but its not secure. I think sips should mean hop by hop, TLS (or equivalent as Dean's text says) secure, and you can't do that on the PSTN. Again, we can work on other security mechanisms that would let an endpoint declare than a PSTN connection was acceptable. That's not sips. Brian > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, November 01, 2006 11:30 AM > To: 'Brian Rosen'; 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP > List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > That isn't even the case in https. When you connect to an https server, > you > have no idea how the back-end gets/stores/updates its info. It could be > creating the page by pulling from another server using tftp as far as you > know. If that https server gets/sends emails using the contents of a > post/get https message, it says nothing about how the emails you read got > to > that server, or how emails you tell it to send are sent. Despite that > your > https post message caused an email to be sent (if it worked that way), the > web server is under no obligation to refuse to send the email, or break > your > https connection, just because it sends them using smtp unsecured. > > -hadriel > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, November 01, 2006 10:01 AM > > To: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List' > > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > > Don't like the PSTN gateway limitation. As was mentioned in an earlier > > > email, if signaling reaches PSTN gateway, it has reached UAS. > > > > Let me relate this to another offshoot of this discussion: when do you > get > > the lock icon? Ignore, just for now, implication on the media channel. > > > > Is there ANY possibility of getting a lock icon on any system using the > > current PSTN or commercial PBX? > > > > I think the only answer possible is "yes, use a STU" (a secure telephone > > that can operate over an ISDN connection). In no other circumstance > would > > anyone consider PSTN or PBX systems to be secure enough to get a lock > icon. > > > > Therefore, I think that if a part of the call traverse a PSTN or PBX > leg, > > it > > is not secured signaling, and sips should fail. > > > > Brian > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 13:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfL5J-00017o-Mt; Wed, 01 Nov 2006 13:45:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfL5H-00017h-PB for sip@ietf.org; Wed, 01 Nov 2006 13:45:07 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfL5D-0006Zg-Ik for sip@ietf.org; Wed, 01 Nov 2006 13:45:07 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfL5P-00044s-FL; Wed, 01 Nov 2006 12:45:15 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 13:44:56 -0500 Message-ID: <00c401c6fde5$d5a89090$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb91jwd5FjPwrCzSKizgKKiKZWDRQAD4X4A In-Reply-To: <4548D0E1.2000904@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'IETF SIP List' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am okay with what Dean wrote for rules. What part of his proposal is problematic for you? Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 01, 2006 11:53 AM > To: Brian Rosen > Cc: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List' > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > Brian, > > While I understand your point, and agree with it for the most part, I am > having trouble turning it into a concrete set of rules. > > In general, there are lots of things that can happen to the call > signaling info, and the media, once it reaches the UAC or UAS. There is > no guarantee that it is ever secure, regardless of the security of the > link between the UAC and UAS: > - info can be displayed on a public display that can be viewed by > parties other than the user of the device > - audio can be played in a way that can be heard by others > - some or all aspects of the session may be relayed to a peripheral > device of the UA, e.g. a bluetooth headset, that is not secured and > can be intercepted by others. > - the user of the UA may let someone else operate the device. > > A PSTN GW is in effect no different than the bluetooth headset in this > regard. Why should we allow one and not the other? > > I think the most one can hope for is that the identity of the remote UA > is known, and that the caller trusts the UA and its user to properly > handle the information conveyed in the call. > > When calling a phone number (e.g. +12125551234), the kinds of > credentials that are available are somewhat dubious. I don't think we > have any form of credential that actually states "I hold the > responsibility for +12125551234". At best I think we may have something > that says: "I have responsibility for sip:+12125551234@provider.com". If > that happens to come from the operator of a gateway, then what it says > about what happens on the other side of the gw is not clear - perhaps > nothing. > > Operationally, this might mean that if I was trying to call > sip:+12125551234@provider.com, and I receive credentials for that back, > and the path between us is secure, then I might consider the call > secure. But if I was calling tel:+12125551234 and I receive back > credentials for sip:+12125551234@provider.com then I might be wise not > to consider this secure. That leaves the problem of whether there is > ever a way to receive credentials for tel:+12125551234. > > Paul > > Brian Rosen wrote: > >> Don't like the PSTN gateway limitation. As was mentioned in an earlier > >> email, if signaling reaches PSTN gateway, it has reached UAS. > > > > Let me relate this to another offshoot of this discussion: when do you > get > > the lock icon? Ignore, just for now, implication on the media channel. > > > > Is there ANY possibility of getting a lock icon on any system using the > > current PSTN or commercial PBX? > > > > I think the only answer possible is "yes, use a STU" (a secure telephone > > that can operate over an ISDN connection). In no other circumstance > would > > anyone consider PSTN or PBX systems to be secure enough to get a lock > icon. > > > > Therefore, I think that if a part of the call traverse a PSTN or PBX > leg, it > > is not secured signaling, and sips should fail. > > > > Brian > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 13:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLAd-0003Ov-BX; Wed, 01 Nov 2006 13:50:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLAb-0003MA-1X for sip@ietf.org; Wed, 01 Nov 2006 13:50:37 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLAZ-0007yr-OB for sip@ietf.org; Wed, 01 Nov 2006 13:50:37 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfLAb-0007CI-JJ; Wed, 01 Nov 2006 12:50:38 -0600 From: "Brian Rosen" To: "'Hadriel Kaplan'" , "'Attila Sipos'" , "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 13:50:19 -0500 Message-ID: <00c501c6fde6$95ac24b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMAAAo5PwAADXtVAABKyl0A== In-Reply-To: <028001c6fdd6$b719ae20$0500a8c0@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think Dean's formulation is a sensible set of rules. It's not airtight, nor could it be. It can be misinterpreted, accidentally or deliberately. I think the intent is clear, and I think the "Best Current Practice" language is clear enough. I don't think that security across one set of UAC to UAS in the presence of B2BUAs and gateways is useful to anyone. I keep imagining TLS protection from UAC to the edge of his own domain, through an SBC across the open Internet with zero security to another domain, with another SBC and TLS from that to the UAS. Does that meet anyone's needs? Does it have anything to do with any sense of secure? I think not. Brian > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, November 01, 2006 11:57 AM > To: 'Brian Rosen'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean > Willis'; 'IETF SIP List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, November 01, 2006 11:14 AM > > > > Clearly, we don't agree. > > > > I would say that the PBX can't provide security to any other call, how > > could > > it possibly provide security to a sips call? One end is insecure. > > It did provide security for a sips session. That session is between the > UAC > and the sips UAS. The UAS is the end, as far as sip/sips is concerned. > Are > you suggesting sips is more than a specific uri scheme for SIP, and > somehow > a cross-protocol, universal fiat, based on an ambiguous definition of > "secure"? :) > > Will the BCP start listing all device types and roles, and whether they > are > allowed to accept a sips request or not? A Bluetooth handset is allowed > to, > a home cablemodem (IAD) with an FXO interface is allowed to, but if that > IAD > is classified as a PBX then not. Unless that "PBX" is an open-source app > in > my house PC. But if my PC gets moved, then it needs to stop accepting > sips. > > > This would be like classifying pornography. "I know it when I see it." > > -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 14:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMAl-0002L2-Jc; Wed, 01 Nov 2006 14:54:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMAk-0002KG-9e for sip@ietf.org; Wed, 01 Nov 2006 14:54:50 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMAg-00059k-M9 for sip@ietf.org; Wed, 01 Nov 2006 14:54:50 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1JsXv01919; Wed, 1 Nov 2006 14:54:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 13:54:30 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6214D1@zrc2hxm2.corp.nortel.com> In-Reply-To: <027901c6fdd3$0876ad80$0500a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAsMboAAHjWjQ From: "Samir Srivastava" To: "Hadriel Kaplan" , "Brian Rosen" , "Sanjay Sinha \(sanjsinh\)" , "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The only difference between trusting the HTTP server and SIP proxy is billing. And it is hop by hop. I mentioned the same case as cheater proxy while discussing the cipher-suites. Here Providers have enough motivation to cheat, if enough checks are not provided. Thx Samir > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, November 01, 2006 8:30 AM > To: 'Brian Rosen'; 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP > List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down >=20 > That isn't even the case in https. When you connect to an https server, > you > have no idea how the back-end gets/stores/updates its info. It could be > creating the page by pulling from another server using tftp as far as you > know. If that https server gets/sends emails using the contents of a > post/get https message, it says nothing about how the emails you read got > to > that server, or how emails you tell it to send are sent. Despite that > your > https post message caused an email to be sent (if it worked that way), the > web server is under no obligation to refuse to send the email, or break > your > https connection, just because it sends them using smtp unsecured. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, November 01, 2006 10:01 AM > > To: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List' > > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > > Don't like the PSTN gateway limitation. As was mentioned in an earlier > > > email, if signaling reaches PSTN gateway, it has reached UAS. > > > > Let me relate this to another offshoot of this discussion: when do you > get > > the lock icon? Ignore, just for now, implication on the media channel. > > > > Is there ANY possibility of getting a lock icon on any system using the > > current PSTN or commercial PBX? > > > > I think the only answer possible is "yes, use a STU" (a secure telephone > > that can operate over an ISDN connection). In no other circumstance > would > > anyone consider PSTN or PBX systems to be secure enough to get a lock > icon. > > > > Therefore, I think that if a part of the call traverse a PSTN or PBX > leg, > > it > > is not secured signaling, and sips should fail. > > > > Brian > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMEP-0003iz-AP; Wed, 01 Nov 2006 14:58:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMEN-0003aX-Ci for sip@ietf.org; Wed, 01 Nov 2006 14:58:35 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMEM-00062c-0S for sip@ietf.org; Wed, 01 Nov 2006 14:58:35 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1JwQv02480; Wed, 1 Nov 2006 14:58:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 13:58:25 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6214EE@zrc2hxm2.corp.nortel.com> In-Reply-To: <00c501c6fde6$95ac24b0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMAAAo5PwAADXtVAABKyl0AABzn2A From: "Samir Srivastava" To: "Brian Rosen" , "Hadriel Kaplan" , "Attila Sipos" , "Sanjay Sinha \(sanjsinh\)" , "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A thought to ponder When Calls on *IP only* are secured, how long PSTN / MGW will last ? I think we are mature enough with enough feature differentials at our hand. Only missing things are security, security .... 911 ... I feel we should just focus on IP only stuff first. Any opinion on this is welcome. For any patches to SIPS to work , I would like to see concrete proposal catering A) How it will interwork with future more elegant / complete proposals. B) How it will transport other URI schemes. C) How it will control the features outside of dialog. Like Presence event Subscribers, REG-EV subscribers D) How it will control the cipher-suite selection? IMHO, let us accept SIPS is broken and not patchable in reasonable way.=20 Thx Samir > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, November 01, 2006 10:50 AM > To: 'Hadriel Kaplan'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean > Willis'; 'IETF SIP List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down >=20 > I think Dean's formulation is a sensible set of rules. It's not airtight, > nor could it be. It can be misinterpreted, accidentally or deliberately. > I > think the intent is clear, and I think the "Best Current Practice" > language > is clear enough. >=20 > I don't think that security across one set of UAC to UAS in the presence > of > B2BUAs and gateways is useful to anyone. I keep imagining TLS protection > from UAC to the edge of his own domain, through an SBC across the open > Internet with zero security to another domain, with another SBC and TLS > from > that to the UAS. Does that meet anyone's needs? Does it have anything to > do with any sense of secure? I think not. >=20 > Brian >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Wednesday, November 01, 2006 11:57 AM > > To: 'Brian Rosen'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean > > Willis'; 'IETF SIP List' > > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, November 01, 2006 11:14 AM > > > > > > Clearly, we don't agree. > > > > > > I would say that the PBX can't provide security to any other call, how > > > could > > > it possibly provide security to a sips call? One end is insecure. > > > > It did provide security for a sips session. That session is between the > > UAC > > and the sips UAS. The UAS is the end, as far as sip/sips is concerned. > > Are > > you suggesting sips is more than a specific uri scheme for SIP, and > > somehow > > a cross-protocol, universal fiat, based on an ambiguous definition of > > "secure"? :) > > > > Will the BCP start listing all device types and roles, and whether they > > are > > allowed to accept a sips request or not? A Bluetooth handset is allowed > > to, > > a home cablemodem (IAD) with an FXO interface is allowed to, but if that > > IAD > > is classified as a PBX then not. Unless that "PBX" is an open-source > app > > in > > my house PC. But if my PC gets moved, then it needs to stop accepting > > sips. > > > > > > This would be like classifying pornography. "I know it when I see it." > > > > -hadriel >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMLn-0003xT-SZ; Wed, 01 Nov 2006 15:06:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMLm-0003xO-9f for sip@ietf.org; Wed, 01 Nov 2006 15:06:14 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMLj-0007Nb-O8 for sip@ietf.org; Wed, 01 Nov 2006 15:06:14 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2006 12:06:11 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1K6BRO003124; Wed, 1 Nov 2006 15:06:11 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1K68DQ016495; Wed, 1 Nov 2006 15:06:11 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:06:08 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:06:08 -0500 Message-ID: <4548FE2F.9050409@cisco.com> Date: Wed, 01 Nov 2006 15:06:07 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <00c401c6fde5$d5a89090$640fa8c0@cis.neustar.com> In-Reply-To: <00c401c6fde5$d5a89090$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 20:06:08.0296 (UTC) FILETIME=[2B5AE280:01C6FDF1] DKIM-Signature: a=rsa-sha1; q=dns; l=5498; t=1162411571; x=1163275571; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:Brian=20Rosen=20; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=rEyNBa8N31pnDQvWIcgovhGbVpZQm2ohoOobCma9uanlmweE+mPYlDbylOqp7OFdAL8bv4Xy 9TwjWtbleV/FOpXmgNpFRVitA+IaV51s3qJCwrA/kxIi5fDMFraBRVU3; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'IETF SIP List' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > I am okay with what Dean wrote for rules. What part of his proposal is > problematic for you? I find much of (4) to be problematic for the reasons stated below. I think the concepts it bans are fuzzy. What exactly is a gateway to another protocol? Is the phone with a bluetooth headset a gateway to the bluetooth protocol? What about B2BUAs bridging two sips requests? What constitutes "bridging" vs a UA that has another sip session for some related purpose? For instance, a UA might accept a SIPS call, and also use SIP (or SIPS) to update a presence server with info about the calls it is in. Others might be able to obtain info (such as the identity of the caller of the currently active call) from the presence server via SIP. Does that disqualify the use of SIPS? And BTW, if we can figure out in what cases a gw may use sips, because it is gatewaying to an equivently strong protocol, then we can use that to show that its ok to use IPsec between a pair of servers. I only see a couple of ways to sort this out: - agree that sips ends when it gets to the UAS. What happens after that must be dealt with some other way. - begin to formally specify types of UA, more than has been done so far. Write specific rules for each type about what it may and may not do when it has a sips connection. This would cover end user devices that signal outside their box, various kinds of gateways, types of SBC and B2BUA, etc. I think it is problematic to do the latter. It can't really be done without considering what the SIPS connection is being used to protect. That gets into our longer term problem which may not even involve sips. So I only see the former as a workable solution. Paul > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, November 01, 2006 11:53 AM >> To: Brian Rosen >> Cc: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List' >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >> >> Brian, >> >> While I understand your point, and agree with it for the most part, I am >> having trouble turning it into a concrete set of rules. >> >> In general, there are lots of things that can happen to the call >> signaling info, and the media, once it reaches the UAC or UAS. There is >> no guarantee that it is ever secure, regardless of the security of the >> link between the UAC and UAS: >> - info can be displayed on a public display that can be viewed by >> parties other than the user of the device >> - audio can be played in a way that can be heard by others >> - some or all aspects of the session may be relayed to a peripheral >> device of the UA, e.g. a bluetooth headset, that is not secured and >> can be intercepted by others. >> - the user of the UA may let someone else operate the device. >> >> A PSTN GW is in effect no different than the bluetooth headset in this >> regard. Why should we allow one and not the other? >> >> I think the most one can hope for is that the identity of the remote UA >> is known, and that the caller trusts the UA and its user to properly >> handle the information conveyed in the call. >> >> When calling a phone number (e.g. +12125551234), the kinds of >> credentials that are available are somewhat dubious. I don't think we >> have any form of credential that actually states "I hold the >> responsibility for +12125551234". At best I think we may have something >> that says: "I have responsibility for sip:+12125551234@provider.com". If >> that happens to come from the operator of a gateway, then what it says >> about what happens on the other side of the gw is not clear - perhaps >> nothing. >> >> Operationally, this might mean that if I was trying to call >> sip:+12125551234@provider.com, and I receive credentials for that back, >> and the path between us is secure, then I might consider the call >> secure. But if I was calling tel:+12125551234 and I receive back >> credentials for sip:+12125551234@provider.com then I might be wise not >> to consider this secure. That leaves the problem of whether there is >> ever a way to receive credentials for tel:+12125551234. >> >> Paul >> >> Brian Rosen wrote: >>>> Don't like the PSTN gateway limitation. As was mentioned in an earlier >>>> email, if signaling reaches PSTN gateway, it has reached UAS. >>> Let me relate this to another offshoot of this discussion: when do you >> get >>> the lock icon? Ignore, just for now, implication on the media channel. >>> >>> Is there ANY possibility of getting a lock icon on any system using the >>> current PSTN or commercial PBX? >>> >>> I think the only answer possible is "yes, use a STU" (a secure telephone >>> that can operate over an ISDN connection). In no other circumstance >> would >>> anyone consider PSTN or PBX systems to be secure enough to get a lock >> icon. >>> Therefore, I think that if a part of the call traverse a PSTN or PBX >> leg, it >>> is not secured signaling, and sips should fail. >>> >>> Brian >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMPt-0000to-8s; Wed, 01 Nov 2006 15:10:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMPs-0000tj-9n for sip@ietf.org; Wed, 01 Nov 2006 15:10:28 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMPr-00085u-1q for sip@ietf.org; Wed, 01 Nov 2006 15:10:28 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2006 12:10:27 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1KAQRL005188; Wed, 1 Nov 2006 15:10:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1KAQDQ017950; Wed, 1 Nov 2006 15:10:26 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:10:23 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:10:22 -0500 Message-ID: <4548FF2E.5000300@cisco.com> Date: Wed, 01 Nov 2006 15:10:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <62B9B0847CC47543B6B3B5E26BD268E60F6214EE@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F6214EE@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 20:10:22.0973 (UTC) FILETIME=[C32782D0:01C6FDF1] DKIM-Signature: a=rsa-sha1; q=dns; l=312; t=1162411826; x=1163275826; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:Samir=20Srivastava=20; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=AElhmY2/3SfwqVe3AfL4NhMQk1uPr+vuBKIDzttdLbuajF9fFGqX6Gzv+PBePq32kbjrREBY OODdtqpl6w8UsUePENy2ImBJIgE5mq5yftyryhIfVsyTw2UxDJF6Zlm2; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List , "Sanjay Sinha \(sanjsinh\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > A thought to ponder > When Calls on *IP only* are secured, how long PSTN / MGW will last ? To be cynical, if IP calls are really secured, then they will probably be ruled illegal. Sellers of equipment and services will be forbidden from offering this capability. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMSk-0007ad-6k; Wed, 01 Nov 2006 15:13:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMSh-0007a1-68 for sip@ietf.org; Wed, 01 Nov 2006 15:13:24 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMSd-0008Rh-S0 for sip@ietf.org; Wed, 01 Nov 2006 15:13:23 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1KDBA00021; Wed, 1 Nov 2006 15:13:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 14:13:09 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F621563@zrc2hxm2.corp.nortel.com> In-Reply-To: <4548FF2E.5000300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb98cdV4jgXlNxPSGeXGmu0uXFvuwAADfEQ From: "Samir Srivastava" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP List , "Sanjay Sinha \(sanjsinh\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >=20 > Samir Srivastava wrote: > > A thought to ponder > > When Calls on *IP only* are secured, how long PSTN / MGW will last ? >=20 > To be cynical, if IP calls are really secured, then they will probably > be ruled illegal. Sellers of equipment and services will be forbidden > from offering this capability. >=20 > You need to have B2BUA in between providing CALEA. We need to specify B2BUA behavior. Thx Samir =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMX9-0003AH-Kg; Wed, 01 Nov 2006 15:17:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMX7-00039b-OU for sip@ietf.org; Wed, 01 Nov 2006 15:17:57 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMX3-0000oP-9V for sip@ietf.org; Wed, 01 Nov 2006 15:17:57 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8200F4XJ221W@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 20:18:02 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6Y1Q>; Wed, 01 Nov 2006 20:17:51 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 20:17:51 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: Francois Audet , Juha Heinanen Message-id: <50B1CBA96870A34799A506B2313F26670A4107D1@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, I disagree. Just securing the signalling is not sufficient to prevent impersonation, for example, unless the media is also authenticated and integrity protected. As a user, what good is it to me if secure signalling tells me that the caller is Francois, yet somebody is sending me unsecured media from a different source? I agree that SIPS != padlock. Therefore I am still trying to discover real use cases for SIPS. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 01 November 2006 17:12 > To: Elwell, John; Juha Heinanen > Cc: Joel M. Halpern; IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > > > > There are cases where you want signalling to be secure (for > > > authentication, impersonation, theft of service, etc.), but > > you don't > > > need, or want, or even can have encrypted media. > > [JRE] No, but you might want authenticated media. It is all > > very well saying that the signalling comes from the person > > you think it comes from, but if the media is coming from > > somewhere else, that doesn't help the average user. > > Sure, but it's a different problem. > > Media security and Signalling security are two different things. > > SIPS is strictly about hop-by-hop signalling security with TLS. > > That's why sips != padlock item, otherwise, you'll give a > false sense of > security to the "average user". > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:23:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMas-0005hd-Fn; Wed, 01 Nov 2006 15:21:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMaq-0005hY-Ua for sip@ietf.org; Wed, 01 Nov 2006 15:21:48 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMao-0001jM-IY for sip@ietf.org; Wed, 01 Nov 2006 15:21:48 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2006 15:21:46 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1KLkZd010403; Wed, 1 Nov 2006 15:21:46 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1KLjDM021770; Wed, 1 Nov 2006 15:21:45 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:21:45 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:21:45 -0500 Message-ID: <454901D8.3040807@cisco.com> Date: Wed, 01 Nov 2006 15:21:44 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <62B9B0847CC47543B6B3B5E26BD268E60F621563@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F621563@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 20:21:45.0233 (UTC) FILETIME=[59D02010:01C6FDF3] DKIM-Signature: a=rsa-sha1; q=dns; l=703; t=1162412506; x=1163276506; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:Samir=20Srivastava=20; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=XuIRXNaMwjFWuWVYUSUoFOt0kECukWEG5CVvBB3+h5oBE7C6CXoG137JOQQ7nK0pRMS3aziS BJDgXXtLTeR8GgCyizuYFRgK9gmlCrHL/MjdXCI1PwD+G+/FyOSDRdRc; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , "Sanjay Sinha \(sanjsinh\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Is a call providing CALEA a secure call? Not in my book. Not if the only two choices are "secure" and "insecure". If there are more than two choices, then "secure except subject to CALEA" might be one of them. Paul Samir Srivastava wrote: > >> Samir Srivastava wrote: >>> A thought to ponder >>> When Calls on *IP only* are secured, how long PSTN / MGW will last ? >> To be cynical, if IP calls are really secured, then they will probably >> be ruled illegal. Sellers of equipment and services will be forbidden >> from offering this capability. >> >> > > You need to have B2BUA in between providing CALEA. We need to specify > B2BUA behavior. > > Thx > Samir > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMhJ-00017S-An; Wed, 01 Nov 2006 15:28:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMhI-00017N-Ba for sip@ietf.org; Wed, 01 Nov 2006 15:28:28 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMhH-00037J-0m for sip@ietf.org; Wed, 01 Nov 2006 15:28:28 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1KSHA03538; Wed, 1 Nov 2006 15:28:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 14:28:11 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6215CE@zrc2hxm2.corp.nortel.com> In-Reply-To: <454901D8.3040807@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb981wgXQyAEyMlRuiS+lC8a39yuAAADnCg From: "Samir Srivastava" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF SIP List , "Sanjay Sinha \(sanjsinh\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As far as I know, FCC will not let you deploy without CALEA compliance. Am I out-of-date on this?=20 IMHO, we will be having security with CALEA. This Security notion is to avoid the Call Pattern tracking etc by attackers but the duly assigned authorities will be open to record the conversation. My view is "Secure except subject to CALEA" . Thx Samir > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 01, 2006 12:22 PM > To: Srivastava, Samir (SC100:8826) > Cc: Brian Rosen; Hadriel Kaplan; Attila Sipos; Sanjay Sinha (sanjsinh); > Dean Willis; IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 > Is a call providing CALEA a secure call? Not in my book. Not if the only > two choices are "secure" and "insecure". If there are more than two > choices, then "secure except subject to CALEA" might be one of them. >=20 > Paul >=20 > Samir Srivastava wrote: > > > >> Samir Srivastava wrote: > >>> A thought to ponder > >>> When Calls on *IP only* are secured, how long PSTN / MGW will last ? > >> To be cynical, if IP calls are really secured, then they will probably > >> be ruled illegal. Sellers of equipment and services will be forbidden > >> from offering this capability. > >> > >> > > > > You need to have B2BUA in between providing CALEA. We need to specify > > B2BUA behavior. > > > > Thx > > Samir > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMkQ-0004wN-3T; Wed, 01 Nov 2006 15:31:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMkO-0004vL-5B for sip@ietf.org; Wed, 01 Nov 2006 15:31:40 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMkL-0003Tp-6Q for sip@ietf.org; Wed, 01 Nov 2006 15:31:40 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1JZBdi020288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 13:35:12 -0600 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D8323@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670A3D8323@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DB43D6E-87ED-45EF-8E71-DF3F50FE17F3@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 14:31:34 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 2:28 AM, Elwell, John wrote: > Dean, > > I think your proposal is moving in the right direction, but I have > a couple > of concerns. See below. In summarization, I think your concerns all involve some variation of knowing "what happened downstream". Specifically, you want to know if: 1) A sip: URI scheme actually produced a dialog with encryption on all hops. You may want to know more about it than "encryption", for example you may want to know what sort of encryption, or what mechanism was used to authenticate the intermediary or terminus. By knowing you had succeeded in getting a secure channel, you could decide to engage other mechanisms (like key exchange) or activities dependent on that security. 2) The security of a sip: or sips: request is degraded (or potentially degraded) by a gateway threshold, beyond which the reporting mechanism has no visibility and which we would generally assume has fully denigrated our cryptographic protections. By knowing the security of sips: is not really end-to-end, you could moderate the invocation of other mechanisms or activities as appropriate for an unsecured channel. I think these are great things to know. I think they go substantially beyond anything we can describe as a BCP for using sip: and sips:. I think this requires new mechanism, perhaps something like a mutant cross between history-info and Samir's cipher-suites draft. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:39:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMpH-0001Cy-BR; Wed, 01 Nov 2006 15:36:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMpF-0001AU-JH for sip@ietf.org; Wed, 01 Nov 2006 15:36:41 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMpE-00044P-5S for sip@ietf.org; Wed, 01 Nov 2006 15:36:41 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1JeEXl020331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 13:40:15 -0600 In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0012A3626@veg-brk-svr-pri.vegastream> References: <8F1F2062CA7D754A838F0E66097D23A0012A3626@veg-brk-svr-pri.vegastream> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 14:36:37 -0600 To: Attila Sipos X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 5:00 AM, Attila Sipos wrote: > >>> Furthermore, gateways to other protocols not >>> offering equally strong protections MUST NOT exercise the sips: URI >>> scheme. In particular, PSTN gateways MUST NOT use sips:, since the >>> PSTN itself does not offer equivalent protections and there is no >>> ability to determine whether the PSTN segment might be >>> converted back to a sip: request somewhere downstream. > > I don't think you will get agreement on this. > > I think this rule will have to be very different. Instead > of saying that we MUST or MUST NOT, it should be a section > on making readers aware of the security implications. > In my opinion, it's a policy thing, not a standards thing. > The 2119-language here is in the requirements of practices, not the requirements for a protocol design. In short, we're saying "If you want to honor the operational requirements of a sips: URI scheme, then you MUST NOT downgrade the protection of the signaling to less than TLS on any hop. If you do, then you have not met the requirements of sips:, and you are lying about your security". In short, you are violating the contract of transitive trust. > There is a benefit in having secure SIP being used upto > the PSTN gateway. > Sure. And with the description of sip: URI processing given earlier (it will be secured if it can be secured) then sip: gives you as good of security as you would get by lying about your compliance with sips:. So placing a call using a sip: URI to the PSTN gateway would produce secure SIP. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMqf-00021q-Qd; Wed, 01 Nov 2006 15:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMqe-00021l-BV for sip@ietf.org; Wed, 01 Nov 2006 15:38:08 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMqd-0004aW-19 for sip@ietf.org; Wed, 01 Nov 2006 15:38:08 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1Jfg4K020349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 13:41:42 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E4FA8CE-144E-46C5-995E-4081EAA6D158@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 14:38:05 -0600 To: Avshalom Houri X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 5:55 AM, Avshalom Houri wrote: > > Seems that we need a mechanism to create a trusted "channel" between > endpoints that goes through all the intermediaries. The channel should > verifiable as secure between the endpoints. After the channel is > created > then the SIP signalling can go securely over the channel. > See: http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt which does exactly what you're describing. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvI-00055z-9O; Wed, 01 Nov 2006 15:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvG-00055t-Ko for sip@ietf.org; Wed, 01 Nov 2006 15:42:54 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMvE-0005fl-Ms for sip@ietf.org; Wed, 01 Nov 2006 15:42:54 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1JkPhm020419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 13:46:26 -0600 In-Reply-To: <000901c6fdbf$a3f04050$2500a8c0@main> References: <000901c6fdbf$a3f04050$2500a8c0@main> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <727B8E94-509B-4C0A-A638-D7FE11678B8F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP Compatible modems/routers? Date: Wed, 1 Nov 2006 14:42:48 -0600 To: Arnoud van Wijk X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 8:11 AM, Arnoud van Wijk wrote: > I am getting this question more and more. Right at home I am using > the IX67 from Intertex. > > But are there other SIP compatible modems or is Intertex still the > only one on this planet? > > > > Such routers/modems must allow end to end SIP. In the LAN and the > WAN. And just SIP to a voice port for analog telephony connection > does not count. All Cisco routers are AFAIK completely SIP compatible. So are most other routers, I suspect. What you want is a SIP-compatible network address translator. That's much harder. One option that may be interesting is to run Asterisk embedded on a Linksys WRT-54GL using the OpenWRT replacement firmware. You can do some neat stuff with that. Or you can run a version of SER on he WRT-54GL, which gives another set of options. But I'd like to point out that this is more of a sip-implementors (or maybe something else entirely) question than it is a SIP mailing list question. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvq-00064Q-AY; Wed, 01 Nov 2006 15:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvo-00061W-BA for sip@ietf.org; Wed, 01 Nov 2006 15:43:28 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMvm-0005oE-JD for sip@ietf.org; Wed, 01 Nov 2006 15:43:28 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1Kgnv26518; Wed, 1 Nov 2006 15:42:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 14:42:48 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F62163A@zrc2hxm2.corp.nortel.com> In-Reply-To: <1E4FA8CE-144E-46C5-995E-4081EAA6D158@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) Thread-Index: Acb99bHwHP0wWSvzRN+BaZ1wbLxZJQAADWrA From: "Samir Srivastava" To: "Dean Willis" , "Avshalom Houri" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My issue with this proposal is what headers are open to proxies to route the initial request. I feel To/From/CallId/ReqUri/Cseq/MAX-FORWARD/via/RecordRoute/Proxy-Require etc.. Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, November 01, 2006 12:38 PM > To: Avshalom Houri > Cc: sip@ietf.org > Subject: Re: What consensus? (was: What controls the lock icon? (Was RE: > [Sip] RE: TLS meaning)) >=20 >=20 >=20 > On Nov 1, 2006, at 5:55 AM, Avshalom Houri wrote: >=20 > > > > Seems that we need a mechanism to create a trusted "channel" between > > endpoints that goes through all the intermediaries. The channel should > > verifiable as secure between the endpoints. After the channel is > > created > > then the SIP signalling can go securely over the channel. > > >=20 > See: >=20 > http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt >=20 > which does exactly what you're describing. >=20 > -- > Dean >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvI-00055z-9O; Wed, 01 Nov 2006 15:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvG-00055t-Ko for sip@ietf.org; Wed, 01 Nov 2006 15:42:54 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMvE-0005fl-Ms for sip@ietf.org; Wed, 01 Nov 2006 15:42:54 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1JkPhm020419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 13:46:26 -0600 In-Reply-To: <000901c6fdbf$a3f04050$2500a8c0@main> References: <000901c6fdbf$a3f04050$2500a8c0@main> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <727B8E94-509B-4C0A-A638-D7FE11678B8F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP Compatible modems/routers? Date: Wed, 1 Nov 2006 14:42:48 -0600 To: Arnoud van Wijk X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 8:11 AM, Arnoud van Wijk wrote: > I am getting this question more and more. Right at home I am using > the IX67 from Intertex. > > But are there other SIP compatible modems or is Intertex still the > only one on this planet? > > > > Such routers/modems must allow end to end SIP. In the LAN and the > WAN. And just SIP to a voice port for analog telephony connection > does not count. All Cisco routers are AFAIK completely SIP compatible. So are most other routers, I suspect. What you want is a SIP-compatible network address translator. That's much harder. One option that may be interesting is to run Asterisk embedded on a Linksys WRT-54GL using the OpenWRT replacement firmware. You can do some neat stuff with that. Or you can run a version of SER on he WRT-54GL, which gives another set of options. But I'd like to point out that this is more of a sip-implementors (or maybe something else entirely) question than it is a SIP mailing list question. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvq-00064Q-AY; Wed, 01 Nov 2006 15:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMvo-00061W-BA for sip@ietf.org; Wed, 01 Nov 2006 15:43:28 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMvm-0005oE-JD for sip@ietf.org; Wed, 01 Nov 2006 15:43:28 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1Kgnv26518; Wed, 1 Nov 2006 15:42:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 14:42:48 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F62163A@zrc2hxm2.corp.nortel.com> In-Reply-To: <1E4FA8CE-144E-46C5-995E-4081EAA6D158@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) Thread-Index: Acb99bHwHP0wWSvzRN+BaZ1wbLxZJQAADWrA From: "Samir Srivastava" To: "Dean Willis" , "Avshalom Houri" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My issue with this proposal is what headers are open to proxies to route the initial request. I feel To/From/CallId/ReqUri/Cseq/MAX-FORWARD/via/RecordRoute/Proxy-Require etc.. Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, November 01, 2006 12:38 PM > To: Avshalom Houri > Cc: sip@ietf.org > Subject: Re: What consensus? (was: What controls the lock icon? (Was RE: > [Sip] RE: TLS meaning)) >=20 >=20 >=20 > On Nov 1, 2006, at 5:55 AM, Avshalom Houri wrote: >=20 > > > > Seems that we need a mechanism to create a trusted "channel" between > > endpoints that goes through all the intermediaries. The channel should > > verifiable as secure between the endpoints. After the channel is > > created > > then the SIP signalling can go securely over the channel. > > >=20 > See: >=20 > http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt >=20 > which does exactly what you're describing. >=20 > -- > Dean >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN1i-0000rk-HJ; Wed, 01 Nov 2006 15:49:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN1h-0000mt-9v for sip@ietf.org; Wed, 01 Nov 2006 15:49:33 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfN1d-00072X-Vc for sip@ietf.org; Wed, 01 Nov 2006 15:49:31 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1Jquxc020466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 13:52:56 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7997E5D5-42B8-42DD-8B8E-9DC1753356C7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 14:49:19 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 10:34 AM, Francois Audet wrote: > There is a difference however between and SBC and PSTN Gateway, in > that > their security model are quite different. How do you know? Specifically, how do you as a UA user on the SIP side of an SBC, B2BUA, or gateway know? All you have is trust that the widget honors the contract of sips:. Sure, if it's a sips: compliant SBC/B2BUA, it could reasonably produce sips: on the other side and stay compliant to the intent of sips:. But if it's converting to anything else (sip:, xmpp, ISDN, ISUP, whatever) it can't maintain the contract of transitive trust implied by sips:, and it MUST therefore NOT use sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN3u-0001j4-3i; Wed, 01 Nov 2006 15:51:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN3s-0001iz-EQ for sip@ietf.org; Wed, 01 Nov 2006 15:51:48 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfN3p-0007Zx-Uu for sip@ietf.org; Wed, 01 Nov 2006 15:51:48 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2006 12:51:46 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="349401364:sNHT53733936" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Kpjkv032071; Wed, 1 Nov 2006 12:51:45 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1KpiW4024526; Wed, 1 Nov 2006 12:51:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:51:44 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:51:44 -0800 Message-ID: <454908DF.1020902@cisco.com> Date: Wed, 01 Nov 2006 15:51:43 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DBCCFA6@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCFA6@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 20:51:44.0524 (UTC) FILETIME=[8A4624C0:01C6FDF7] DKIM-Signature: a=rsa-sha1; q=dns; l=2928; t=1162414305; x=1163278305; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DF7vmGn+0mljziVnIPpUyEGg5x4g=3D; b=emS+eDMzaK0UCFG7XaMpi3HHuCf6iIXNuPp/FmpJO/5pYvUIIIHsnFh/PlLe1EenlBoAcVy/ PCCzRZDOrsJDhh/vIn6Lt64YK+MbktEUcdqxyNjvlQcH6lkYlvdrCq/V; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, many messages have come and gone since this one. So, I will respond to Francois's note here and make some additional points. My own opinion: 1. no 2. yes I fear that much of the objection to sips is wound up in its name. Its not "secure SIP" in the sense that there are certainly attacks that remain even if you use it. However, there is really no such thing as "secure SIP", anymore than there is really such a thing as "secure HTTP". I'll point out that with attacks like phishing, even https isn't providing people with what they think is "secure web browsing". But let us not throw the baby out with the bathwater. What SIPS can do, once we fix it, is provide a particular property that I think is very valuable. In networks with trusted proxies, it prevents against a vast array of "outsider" attacks - eavesdropping, replay, modification, and so on. This property is very useful. I can't tell you how many SIP extensions have security considerations that are based on this property. Just because sips doesn't address insider attacks (where the proxies are not trusted), does not make it useless. To be frank I fear there will never be a deployable solution for security where you don't trust the proxies. Its kind of like hoping the Internet works when you don't trust the routers. It would be nice but it sounds hard. I believe we have also learned a lot since RFC 3261. WIth the arrival of sip-outbound, I believe we have the final tool needed to remove the last hop exception rule, and have a very useful security technique that is also extremely deployable. If you throw in DTLS as "ok" as well, you can even get around the TCP/UDP wars, and provide something that works for wireless too. My two cents, Jonathan R. Francois Audet wrote: > In case people having noticed, it is looking like we are having a > mailing list > hum on the following 2 questions: > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) > > 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) > > > Note: Voting Yes on 2 does not necessarily imply you are voting No on 1, > but it will > only make sense if sips is not deprecated. > > I'm keeping track of the vote. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:55:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN5R-0003pF-U1; Wed, 01 Nov 2006 15:53:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN5P-0003hm-F7 for sip@ietf.org; Wed, 01 Nov 2006 15:53:23 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfN5O-0007s8-3n for sip@ietf.org; Wed, 01 Nov 2006 15:53:23 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8200LAMKP7FR@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 20:53:31 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6YLH>; Wed, 01 Nov 2006 20:53:20 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 20:53:20 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Samir Srivastava , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A4107D8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List , "Sanjay Sinha \(sanjsinh\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir, When I submit confidential information to a web site over HTTPS I can check the certificate and see that I am indeed sending information to MyBank.com (of course, I have to trust MyBank.com to treat the information appropriately once it gets there). Now if I want to do similar over a SIP-initiated session, then likewise I want to see a caller/callee identity signed by MyBank.com with media security bound to that identity in some way. If instead I see a certificate for InterceptingServiceProvider.net, I will be disinclined to submit confidential information and will find other ways (e.g., HTTPS) to do the same thing. SIP becomes relegated to a PSTN replacement or worse. John > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: 01 November 2006 20:28 > To: Paul Kyzivat > Cc: IETF SIP List; Sanjay Sinha (sanjsinh); Dean Willis > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > As far as I know, FCC will not let you deploy without CALEA > compliance. > Am I out-of-date on this? > > IMHO, we will be having security with CALEA. This Security > notion is to > avoid the Call Pattern tracking etc by attackers but the duly assigned > authorities will be open to record the conversation. > > My view is "Secure except subject to CALEA" . > > Thx > Samir > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, November 01, 2006 12:22 PM > > To: Srivastava, Samir (SC100:8826) > > Cc: Brian Rosen; Hadriel Kaplan; Attila Sipos; Sanjay Sinha > (sanjsinh); > > Dean Willis; IETF SIP List > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > > Is a call providing CALEA a secure call? Not in my book. Not if the > only > > two choices are "secure" and "insecure". If there are more than two > > choices, then "secure except subject to CALEA" might be one of them. > > > > Paul > > > > Samir Srivastava wrote: > > > > > >> Samir Srivastava wrote: > > >>> A thought to ponder > > >>> When Calls on *IP only* are secured, how long PSTN / > MGW will last > ? > > >> To be cynical, if IP calls are really secured, then they will > probably > > >> be ruled illegal. Sellers of equipment and services will be > forbidden > > >> from offering this capability. > > >> > > >> > > > > > > You need to have B2BUA in between providing CALEA. We need to > specify > > > B2BUA behavior. > > > > > > Thx > > > Samir > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 15:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN5h-00057H-WC; Wed, 01 Nov 2006 15:53:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN5g-0004wX-Ft for sip@ietf.org; Wed, 01 Nov 2006 15:53:40 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfN5e-0007v4-Vh for sip@ietf.org; Wed, 01 Nov 2006 15:53:40 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J820014SKPO1O@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 20:53:48 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6YLK>; Wed, 01 Nov 2006 20:53:37 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 20:53:37 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Francois Audet , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A4107D9@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, The point about PSTN is that although it might be considered secure by some people (although I have seen statements to the contrary), there is no way of knowing what happens beyond the PSTN. There could be some other IP network that does not apply security. Therefore there is always an element of doubt over PSTN. However, if we retain SIPS (the need for which I am not yet convinced of) then I think it is equally valid as far as the gateway, and the job of indicating that there is some question mark over security beyond the gateway should be addressed by some other means. As Paul says, an identity such as sips:+12125551234@provider.com would tell you that you have a secure connection to provider.com, and says nothing about what happens beyond that. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 01 November 2006 17:23 > To: Paul Kyzivat > Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List; Dean Willis > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, November 01, 2006 9:05 AM > > To: Audet, Francois (SC100:3055) > > Cc: Dean Willis; Sanjay Sinha ((sanjsinh)); IETF SIP List > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > > > > > > Francois Audet wrote: > > > There is a difference however between and SBC and PSTN > Gateway, in > > > that their security model are quite different. > > > > I don't see the difference. > > > > In either case, the call has reached a UA. From that point on > > you are trusting that the UA will do the right thing. The > > best you can do is determine the identity of that UA and > > decide if it is one you wish to trust. > > The difference is that there is a level of "security" on > PSTN. You can't > do IP address spoofing for example. You can't tap into a hub. > > (Yes, I know: there are ways to tap into analog lines too). > > The point is that for many people, they are happy with the security > level provided by the PSTN, but not with the one provided by IP > telephony > or SIP when there is no TLS/SRTP/whatever. > > That's my point. > > So, I can see that, as Michael Thomas said, putting all the > "attributes > of security" into the letter "s" is not terribly useful. > > On the specific issue of "is sips allowed" when you leave the > "network", > I am a bit > ambivalent. > > I think if you are Leaving SIP and going to another IP protocol (say > H.323) then we > shouldn't allow SIPs. > > However, for the PSTN case, I'm not sure. I think I'm ok either way. I > think arguments > on both sides are valid. > > > > > If you have phone service from a provider that uses SBCs at > > its connection to the internet, when I call "you" I am really > > calling that SBC. All security and authentication properties > > are with it, not you or your devices. I must trust it. The > > same is true if I call a gateway. > > > > Paul > > > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> Sent: Tuesday, October 31, 2006 9:23 PM > > >> To: Sanjay Sinha ((sanjsinh)) > > >> Cc: IETF SIP List > > >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > >> > > >> > > >> On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote: > > >> > > >>> It is my understanding is that SBC is esentially a B2BUA or > > >> an IP-IP > > >>> gateway, if one leg is SIP and another one is say, > > >> H323/MGCP. A pstn > > >>> gateway is termination point of IP leg signaling. It will > > have fxs/ > > >>> pots or a PBX interface on the other leg. So I can have > > an IAD with > > >>> pots phones hanging off of fxs port in a small branch > > >> office and know > > >>> that interface is secure/trusted. > > >>> > > >> Ok, that's fair. I wouldn't describe that as a PSTN > > Gateway so much > > >> as I would describe it as a multi-user UA that uses telephone > > >> handsets to implement its user interface devices. > > >> By the same token, it would be OK to run sips: to a Mac > > that uses a > > >> Bluetooth headset, even though Bluetooth isn't TLS. > > >> > > >> By PSTN gateway, I mean a box that converts the SIP call into a > > >> signaled call on a PSTN line (especially a "trunk" line). > > >> > > >> Of course, once you stick an fxo line on that > multiuser-UA box and > > >> start pumping calls back into the P (that's Public) STN, > > you have a > > >> security problem again. This could easily happen with a > > PBX, so that > > >> could be a problem. It might be legit to say that a PBX > > simply can't > > >> do sips:, because it can't meet the security assurances of sips:. > > >> > > >> -- > > >> 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 > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN99-0004B7-RE; Wed, 01 Nov 2006 15:57:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfN98-00048o-2w for sip@ietf.org; Wed, 01 Nov 2006 15:57:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfN95-0000Df-PK for sip@ietf.org; Wed, 01 Nov 2006 15:57:14 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1K0fdD020542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:00:42 -0600 In-Reply-To: <4548D0E1.2000904@cisco.com> References: <003801c6fdc6$9e440e50$640fa8c0@cis.neustar.com> <4548D0E1.2000904@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C7E77B3-2986-44CE-9D8C-1D88777807DF@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 14:57:03 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 10:52 AM, Paul Kyzivat wrote: > > A PSTN GW is in effect no different than the bluetooth headset in > this regard. Why should we allow one and not the other? > That depends on what you mean by PSTN Gateway. If you're talking about a "phone adapter", like a PAP-2 or larger enterprise scale device, then you're talking about the user interface of a SIP UA, and sips: is ok. OTOH, if you're talking about a device that converts the SIP signaling into some other signaling format (ISDN, ISUP, MF DTMF, XMPP, whatever) and transmits the results to another switching element, then you're well outside the applicability of sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNBI-0004zK-45; Wed, 01 Nov 2006 15:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNBG-0004yM-LU for sip@ietf.org; Wed, 01 Nov 2006 15:59:26 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNBF-0000f1-7X for sip@ietf.org; Wed, 01 Nov 2006 15:59:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 20:59:24 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A362B@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down thread-index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMAAAo5PwAADXtVAABKyl0AADg1mg From: "Attila Sipos" To: "Brian Rosen" , "Hadriel Kaplan" , "Sanjay Sinha (sanjsinh)" , "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Internet with zero security to another domain, with another=20 >> SBC and TLS from >> that to the UAS. Does that meet anyone's needs? Does it=20 >> have anything to >> do with any sense of secure? The scenario described could not be secure, of course not. And no-one would argue with that. However that is not the same as saying that SIPS can't be considered "secure enough" for it's purpose. There are various levels of security but it all about what people would consider acceptable. I think a call going to a SIPS/PBX gateway to a physically secure PBX to a phone would be considered secure enough by most people. An organization would probably consider their PBX to be secure but would also like some security for SIP calls too. SIPS should be able to provide this. There are so many scenarios where SIPS would be useful for a PBX gateway and even for a PSTN gateway. It is not about absolute security but about what is deemed acceptable. This issue is also about trust. We have to trust the things we're calling. We have to trust the people we're calling. We make a secure call to them and we trust that they're not going to broadcast=20 what you're saying on their speakerphone. We trust that they don't mike up your call and put it out on the PA. It could also be a political thing. People might consider PSTN to be quite safe but might consider computer networks to be unsafe. So the solution is to use SIPS for the computer network part of the call to give people some sense of security. SIPS to PSTN/PBX/ISDN gateway calls have to considered in the context of their environment. 1. what is the required level of security? 2. is there trust? 3. is there a benefit? The second one is more important than anything. What good is a company which offers a super secure solution if no-one trusts them? Attila >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: 01 November 2006 18:50 >> To: 'Hadriel Kaplan'; Attila Sipos; 'Sanjay Sinha (sanjsinh)'; 'Dean >> Willis'; 'IETF SIP List' >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >>=20 >>=20 >> I think Dean's formulation is a sensible set of rules. It's=20 >> not airtight, >> nor could it be. It can be misinterpreted, accidentally or=20 >> deliberately. I >> think the intent is clear, and I think the "Best Current=20 >> Practice" language >> is clear enough. =20 >>=20 >> I don't think that security across one set of UAC to UAS in=20 >> the presence of >> B2BUAs and gateways is useful to anyone. I keep imagining=20 >> TLS protection >> from UAC to the edge of his own domain, through an SBC=20 >> across the open >> Internet with zero security to another domain, with another=20 >> SBC and TLS from >> that to the UAS. Does that meet anyone's needs? Does it=20 >> have anything to >> do with any sense of secure? I think not. >>=20 >> Brian=20 >>=20 >> > -----Original Message----- >> > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> > Sent: Wednesday, November 01, 2006 11:57 AM >> > To: 'Brian Rosen'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean >> > Willis'; 'IETF SIP List' >> > Subject: RE: [Sip] A sips: trial balloon for you to shoot down >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Brian Rosen [mailto:br@brianrosen.net] >> > > Sent: Wednesday, November 01, 2006 11:14 AM >> > > >> > > Clearly, we don't agree. >> > > >> > > I would say that the PBX can't provide security to any=20 >> other call, how >> > > could >> > > it possibly provide security to a sips call? One end is=20 >> insecure. >> >=20 >> > It did provide security for a sips session. That session=20 >> is between the >> > UAC >> > and the sips UAS. The UAS is the end, as far as sip/sips=20 >> is concerned. >> > Are >> > you suggesting sips is more than a specific uri scheme for SIP, and >> > somehow >> > a cross-protocol, universal fiat, based on an ambiguous=20 >> definition of >> > "secure"? :) >> >=20 >> > Will the BCP start listing all device types and roles, and=20 >> whether they >> > are >> > allowed to accept a sips request or not? A Bluetooth=20 >> handset is allowed >> > to, >> > a home cablemodem (IAD) with an FXO interface is allowed=20 >> to, but if that >> > IAD >> > is classified as a PBX then not. Unless that "PBX" is an=20 >> open-source app >> > in >> > my house PC. But if my PC gets moved, then it needs to=20 >> stop accepting >> > sips. >> >=20 >> >=20 >> > This would be like classifying pornography. "I know it=20 >> when I see it." >> >=20 >> > -hadriel >>=20 >>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:02:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNCO-0005nK-RE; Wed, 01 Nov 2006 16:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNCN-0005ma-H6 for sip@ietf.org; Wed, 01 Nov 2006 16:00:35 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNCM-0000r8-1M for sip@ietf.org; Wed, 01 Nov 2006 16:00:35 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1K488M020602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:04:08 -0600 In-Reply-To: <4548D39F.8050905@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> <4548D39F.8050905@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:00:31 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 11:04 AM, Paul Kyzivat wrote: > If you have phone service from a provider that uses SBCs at its > connection to the internet, when I call "you" I am really calling > that SBC. All security and authentication properties are with it, > not you or your devices. I must trust it. The same is true if I > call a gateway. The point is that you are trusting the SBC to perform in a manner consistent with the intent of sips:. By accepting the sips: connection, it has essentially contracted with you to comply with sips:. If it does NOT comply with the intent of sips: and translates the dialog into something that isn't protected and is then "sent out" beyond its immediate sphere of control (its user interface, if it is a UA), then it has failed to honor that contract. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:03:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNDn-0006fq-RY; Wed, 01 Nov 2006 16:02:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNDm-0006fl-Ag for sip@ietf.org; Wed, 01 Nov 2006 16:02:02 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNDl-0000yW-27 for sip@ietf.org; Wed, 01 Nov 2006 16:02:02 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id AB400678; Wed, 01 Nov 2006 16:01:52 -0500 From: "Hadriel Kaplan" To: "'Brian Rosen'" , "'Attila Sipos'" , "'Sanjay Sinha \(sanjsinh\)'" , "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 16:01:52 -0500 Message-ID: <00b501c6fdf8$f4b50aa0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00c501c6fde6$95ac24b0$640fa8c0@cis.neustar.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLAACnN6SAAAduTMAAAo5PwAADXtVAABKyl0AADQrKw X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, November 01, 2006 1:50 PM > To: 'Hadriel Kaplan'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean > Willis'; 'IETF SIP List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > I think Dean's formulation is a sensible set of rules. It's not airtight, > nor could it be. It can be misinterpreted, accidentally or deliberately. > I > think the intent is clear, and I think the "Best Current Practice" > language > is clear enough. > > I don't think that security across one set of UAC to UAS in the presence > of > B2BUAs and gateways is useful to anyone. I keep imagining TLS protection > from UAC to the edge of his own domain, through an SBC across the open > Internet with zero security to another domain, with another SBC and TLS > from > that to the UAS. Does that meet anyone's needs? Does it have anything to > do with any sense of secure? I think not. Well, I was actually only focusing on the PSTN GW restriction. One can of worms at a time as it were. :) I actually think a layman typing in a sips uri would be fine with it going to the PSTN. And I think trying to make any suppositions of their wishes beyond the sips domain is virtually impossible. With respect to SBCs, my assumption is an SBC will keep a SIPS request received as a UAS a SIPS request as a UAC, reject it if it cannot do so, etc. Unless, of course, it's specifically told to do otherwise by its owner. I have a sneaking suspicion that would be the case of many stateful "proxies" too. (in fact, I know of two that can do otherwise if set to) But if the owner set it to be clear on the public internet, they've created a security issue for which they would have to take some responsibility (maybe... IANAL). If you just want a BCP to say "a B2BUA or SBC should keep a sips request a sips request", with all that entails, I'm cool with that. But throwing in a PSTN GW, PBX, IAD, MTA, Key-system, etc. is wrong, IMHO. It is neither Best nor Current Practice. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFj-0008E0-5P; Wed, 01 Nov 2006 16:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFi-0008Dq-BT for sip@ietf.org; Wed, 01 Nov 2006 16:04:02 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNFf-0001C1-Ik for sip@ietf.org; Wed, 01 Nov 2006 16:04:02 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1K7U07020680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:07:31 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE8237@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DCE8237@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <183FF21E-1791-4AA8-83FF-6584F3DA5D65@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:03:53 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 11:23 AM, Francois Audet wrote: > The difference is that there is a level of "security" on PSTN. You > can't > do IP address spoofing for example. You can't tap into a hub. > > (Yes, I know: there are ways to tap into analog lines too). > > The point is that for many people, they are happy with the security > level provided by the PSTN, but not with the one provided by IP > telephony > or SIP when there is no TLS/SRTP/whatever. > > That's my point. > > So, I can see that, as Michael Thomas said, putting all the > "attributes > of security" into the letter "s" is not terribly useful. > > On the specific issue of "is sips allowed" when you leave the > "network", > I am a bit > ambivalent. > > I think if you are Leaving SIP and going to another IP protocol (say > H.323) then we > shouldn't allow SIPs. > > However, for the PSTN case, I'm not sure. I think I'm ok either way. I > think arguments > on both sides are valid. Since the PSTN call could (and very well may) turn back into a sip: session, and we have no way to send the "please make this back into a secure session when you go back to IP" request over PSTN, then I don't think you can claim to have met the intent of sips:. That's not to say a gateway couldn't use SIP security techniques -- for example, it could (and should) use TLS. It just can't claim to have met the requirements of sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFR-0007uw-9A; Wed, 01 Nov 2006 16:03:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFP-0007sT-7s for sip@ietf.org; Wed, 01 Nov 2006 16:03:43 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNFN-0001Ah-UD for sip@ietf.org; Wed, 01 Nov 2006 16:03:43 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J820019BL6F1O@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 21:03:51 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6YNB>; Wed, 01 Nov 2006 21:03:40 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 21:03:40 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Dean Willis Message-id: <50B1CBA96870A34799A506B2313F26670A4107DB@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Not quite. See below. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 01 November 2006 20:32 > To: Elwell, John > Cc: IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > On Nov 1, 2006, at 2:28 AM, Elwell, John wrote: > > > Dean, > > > > I think your proposal is moving in the right direction, but I have > > a couple > > of concerns. See below. > > In summarization, I think your concerns all involve some > variation of > knowing "what happened downstream". Specifically, you want to know if: > > 1) A sip: URI scheme actually produced a dialog with encryption on > all hops. You may want to know more about it than "encryption", for > example you may want to know what sort of encryption, or what > mechanism was used to authenticate the intermediary or terminus. By > knowing you had succeeded in getting a secure channel, you could > decide to engage other mechanisms (like key exchange) or activities > dependent on that security. [JRE] If we have a sips scheme that mandates TLS on all hops (whatever TLS might mean) and fails if it can't achieve it, I think there is an equal argument for a mechanism that requests TLS on all hops but still succeeds and tells me if any hop does not meet this requirement. So if we recommend the sip scheme for achieving best effort, it still doesn't tell me if it succeeded. Yes, what I want would be a new mechanism, but it would not be substantially more difficult to define than the SIPS mechanism. I am having a hard time rationalising why we should specify an all-or-nothing mechanism (sips) but not a best effort mechanism. In other words I am having a hard time understanding the use cases for sips. Maybe the lack of plausible use cases is part of the reason it hasn't been deployed much. > > 2) The security of a sip: or sips: request is degraded (or > potentially degraded) by a gateway threshold, beyond which the > reporting mechanism has no visibility and which we would generally > assume has fully denigrated our cryptographic protections. By > knowing > the security of sips: is not really end-to-end, you could moderate > the invocation of other mechanisms or activities as appropriate for > an unsecured channel. > > I think these are great things to know. I think they go > substantially > beyond anything we can describe as a BCP for using sip: and sips:. I > think this requires new mechanism, perhaps From sip-bounces@ietf.org Wed Nov 01 16:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFj-0008E0-5P; Wed, 01 Nov 2006 16:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFi-0008Dq-BT for sip@ietf.org; Wed, 01 Nov 2006 16:04:02 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNFf-0001C1-Ik for sip@ietf.org; Wed, 01 Nov 2006 16:04:02 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1K7U07020680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:07:31 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE8237@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DCE8237@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <183FF21E-1791-4AA8-83FF-6584F3DA5D65@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:03:53 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 11:23 AM, Francois Audet wrote: > The difference is that there is a level of "security" on PSTN. You > can't > do IP address spoofing for example. You can't tap into a hub. > > (Yes, I know: there are ways to tap into analog lines too). > > The point is that for many people, they are happy with the security > level provided by the PSTN, but not with the one provided by IP > telephony > or SIP when there is no TLS/SRTP/whatever. > > That's my point. > > So, I can see that, as Michael Thomas said, putting all the > "attributes > of security" into the letter "s" is not terribly useful. > > On the specific issue of "is sips allowed" when you leave the > "network", > I am a bit > ambivalent. > > I think if you are Leaving SIP and going to another IP protocol (say > H.323) then we > shouldn't allow SIPs. > > However, for the PSTN case, I'm not sure. I think I'm ok either way. I > think arguments > on both sides are valid. Since the PSTN call could (and very well may) turn back into a sip: session, and we have no way to send the "please make this back into a secure session when you go back to IP" request over PSTN, then I don't think you can claim to have met the intent of sips:. That's not to say a gateway couldn't use SIP security techniques -- for example, it could (and should) use TLS. It just can't claim to have met the requirements of sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFR-0007uw-9A; Wed, 01 Nov 2006 16:03:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNFP-0007sT-7s for sip@ietf.orgsomething like a mutant > cross between history-info and Samir's cipher-suites draft. > > -- > 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 ; Wed, 01 Nov 2006 16:03:43 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNFN-0001Ah-UD for sip@ietf.org; Wed, 01 Nov 2006 16:03:43 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J820019BL6F1O@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 21:03:51 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6YNB>; Wed, 01 Nov 2006 21:03:40 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 21:03:40 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Dean Willis Message-id: <50B1CBA96870A34799A506B2313F26670A4107DB@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Not quite. See below. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 01 November 2006 20:32 > To: Elwell, John > Cc: IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > On Nov 1, 2006, at 2:28 AM, Elwell, John wrote: > > > Dean, > > > > I think your proposal is moving in the right direction, but I have > > a couple > > of concerns. See below. > > In summarization, I think your concerns all involve some > variation of > knowing "what happened downstream". Specifically, you want to know if: > > 1) A sip: URI scheme actually produced a dialog with encryption on > all hops. You may want to know more about it than "encryption", for > example you may want to know what sort of encryption, or what > mechanism was used to authenticate the intermediary or terminus. By > knowing you had succeeded in getting a secure channel, you could > decide to engage other mechanisms (like key exchange) or activities > dependent on that security. [JRE] If we have a sips scheme that mandates TLS on all hops (whatever TLS might mean) and fails if it can't achieve it, I think there is an equal argument for a mechanism that requests TLS on all hops but still succeeds and tells me if any hop does not meet this requirement. So if we recommend the sip scheme for achieving best effort, it still doesn't tell me if it succeeded. Yes, what I want would be a new mechanism, but it would not be substantially more difficult to define than the SIPS mechanism. I am having a hard time rationalising why we should specify an all-or-nothing mechanism (sips) but not a best effort mechanism. In other words I am having a hard time understanding the use cases for sips. Maybe the lack of plausible use cases is part of the reason it hasn't been deployed much. > > 2) The security of a sip: or sips: request is degraded (or > potentially degraded) by a gateway threshold, beyond which the > reporting mechanism has no visibility and which we would generally > assume has fully denigrated our cryptographic protections. By > knowing > the security of sips: is not really end-to-end, you could moderate > the invocation of other mechanisms or activities as appropriate for > an unsecured channel. > > I think these are great things to know. I think they go > substantially > beyond anything we can describe as a BCP for using sip: and sips:. I > think this requires new mechanism, perhaps something like a mutant > cross between history-info and Samir's cipher-suites draft. > > -- > Dean > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNH4-00014r-8r; Wed, 01 Nov 2006 16:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNH2-00013Z-Hv for sip@ietf.org; Wed, 01 Nov 2006 16:05:24 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNH1-0001Jp-7R for sip@ietf.org; Wed, 01 Nov 2006 16:05:24 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1L5JA27467; Wed, 1 Nov 2006 16:05:19 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Wed, 1 Nov 2006 15:05:17 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE86CF@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4107D1@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb98yXYov/mVULqRTmCqLM7P7MPpAABh2kg From: "Francois Audet" To: "Elwell, John" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You mean doing IP address spoofing? If you don't like impersonation, take theft of service then. My point is that I have seen places where signalling security was a requirement but not media security.=20 It does exist in real life.=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Wednesday, November 01, 2006 12:18 PM > To: Audet, Francois (SC100:3055); Juha Heinanen > Cc: Joel M. Halpern; IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > Francois, >=20 > I disagree. Just securing the signalling is not sufficient to=20 > prevent impersonation, for example, unless the media is also=20 > authenticated and integrity protected. As a user, what good=20 > is it to me if secure signalling tells me that the caller is=20 > Francois, yet somebody is sending me unsecured media from a=20 > different source? >=20 > I agree that SIPS !=3D padlock. Therefore I am still trying to=20 > discover real use cases for SIPS. >=20 > John=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 01 November 2006 17:12 > > To: Elwell, John; Juha Heinanen > > Cc: Joel M. Halpern; IETF SIP List > > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > > TLS meaning) > >=20 > > =20 > > > > There are cases where you want signalling to be secure (for=20 > > > > authentication, impersonation, theft of service, etc.), but > > > you don't > > > > need, or want, or even can have encrypted media. > > > [JRE] No, but you might want authenticated media. It is all very=20 > > > well saying that the signalling comes from the person you=20 > think it=20 > > > comes from, but if the media is coming from somewhere else, that=20 > > > doesn't help the average user. > >=20 > > Sure, but it's a different problem. > >=20 > > Media security and Signalling security are two different things. > >=20 > > SIPS is strictly about hop-by-hop signalling security with TLS.=20 > >=20 > > That's why sips !=3D padlock item, otherwise, you'll give a=20 > false sense=20 > > of security to the "average user". > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:07:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNHW-0001T4-3N; Wed, 01 Nov 2006 16:05:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNHV-0001Ss-5R for sip@ietf.org; Wed, 01 Nov 2006 16:05:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNHT-0001M2-Ig for sip@ietf.org; Wed, 01 Nov 2006 16:05:52 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 01 Nov 2006 13:05:50 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="447612638:sNHT830714676" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1L5okp014412; Wed, 1 Nov 2006 13:05:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1L5oW4008099; Wed, 1 Nov 2006 13:05:50 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 13:05:50 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:05:49 -0800 Message-ID: <45490C2C.3060606@cisco.com> Date: Wed, 01 Nov 2006 16:05:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> In-Reply-To: <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 21:05:49.0583 (UTC) FILETIME=[81F7E9F0:01C6FDF9] DKIM-Signature: a=rsa-sha1; q=dns; l=2720; t=1162415150; x=1163279150; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:SIP=20as=20an=20alternative=20to=20IKE?, =20was=3A=20Re=3A=20[Sip]=20RE=3 A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DJbFFnP8wvqTGZxlY8ux8dfVr8UE=3D; b=XbFIOnWZ+wmuyYlk9gViDAjlq7EWuPgbi9WiU5iuAFnRsAzu0Gu2Eli/jpWWwrmkvLEoOlhv sMRP7LXh58E41N+kkzyLQTGLhz5sQWxQpKvTo1RKIcNP+ChTYs/MKjxs; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "Joel M. Halpern" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org rant inline. Dean Willis wrote: > > But please help us understand what's different about IPSEC usage in the > IMS sense. > > IMS has a persistent IPSEC SA established between the edge proxy and > the UA. Authentication is accomplished using the SIM as a token > generator, and the crypto is one of the usual mechanisms (keep in mind > TLS still allows plain small-key DES, which isn't all that strong). The > applications are constructed so that the SIP function is aware of the > SA and that it is connected to an authenticated party. Well, now you're going to get me started on how bad the IMS IPSec mechanism is. Its IPSEC, sure, but its keyed with a horrific tunnel-keys-through-SIP-register mechanism. Given the immense complication in designing secure keying protocols, I have a deep fear that there is a lurking security hole in the way keying works in IMS. Indeed, the specifications for this 'keying' protocol are about as opaque as you can make them. They are deeply buried within IMS specifications, bundled with lots of other stuff. This makes it nearly impossible for broad analysis and critique from the security community, which includes many folks (if not most) that would never be able to penetrate the IMS specifications in order to comment. I'll also note that it is a massive layer violation; we're using an application layer protocol to key a security protocol over which that very same application layer protocol will run. Does that not simply strike you as absurd? From an implementation perspective, the IMS security mechanism is a nightmare. You can't use "standard" offloaders, since those assume standardized keying mechanisms, not this insanity of using SIP for keying. This makes IMS servers more expensive. You need to deeply integrate your IPSec and SIP stacks. Awful!! If TCP is the stumbling block to using TLS in IMS, then DTLS to me would be a blessing. Nothing would please me more than to deprecate the specs that define this nightmare. Two in particular - the seemingly innocuous RFC4169 which opens the door for sip-as-a-keying-protocol, and the even more horrible RFC3329, which hides its real agenda of adding bid-down prevention to SIP-the-IPSec-keying-protocol. Once deprecated, we can tell 3gpp to use SIP over DTLS in R8. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNIw-0002Jz-U3; Wed, 01 Nov 2006 16:07:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNIv-0002Jn-AV for sip@ietf.org; Wed, 01 Nov 2006 16:07:21 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNIu-0001eP-0J for sip@ietf.org; Wed, 01 Nov 2006 16:07:21 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1KArF7020736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:10:54 -0600 In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E024D2D06@xmb-rtp-215.amer.cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E024D2D06@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:07:15 -0600 To: Sanjay Sinha ((sanjsinh)) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 12:35 PM, Sanjay Sinha ((sanjsinh)) wrote: >> -----Original Message----- >> From: David Benoit [mailto:benoit@infointeractive.com] >> Sent: Wednesday, November 01, 2006 10:28 AM >> To: Sanjay Sinha (sanjsinh) >> Cc: IETF SIP List; Dean Willis >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >> >> On Tue, Oct 31, 2006 at 02:00:51PM -0500, Sanjay Sinha >> (sanjsinh) wrote: >>> Don't like the PSTN gateway limitation. As was mentioned in >> an earlier >>> email, if signaling reaches PSTN gateway, it has reached UAS. >> >> I think you mean UAC. As far as SIP is concerned, the gateway >> is the client. > No I meant UAS. For a call originated from a SIP UA to a pstn user, > gateway is acting like a UAS. > Right. And all of the signaling from SIP is being mapped into some other signaling protocol and sent beyond a transitive trust boundary. The gateway simply doesn't know where its goingor what is going to happen "out there". Consequently, the gateway knows that it cannot assure transitive trust with respect to signaling integraity, and since it cannot insure transitive trust, it cannot use sips:. Using sips: means "I guarantee that you can trust me to make sure this channel is protected to the minimal standard defined by sips:". If you can't meet that commitment, you just can't use sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNKx-0004V2-QT; Wed, 01 Nov 2006 16:09:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNKw-0004St-BW for sip@ietf.org; Wed, 01 Nov 2006 16:09:26 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNKu-0001yZ-Vb for sip@ietf.org; Wed, 01 Nov 2006 16:09:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 21:09:24 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A362C@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down thread-index: Acb99XLqfdzBCmH2ShKlLdaYLfPdrQABAcZg From: "Attila Sipos" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> In short, we're saying "If you =20 >> want to honor the operational requirements of a sips: URI scheme, =20 >> then you MUST NOT downgrade the protection of the signaling to less =20 >> than TLS on any hop. If you do, then you have not met the =20 >> requirements of sips:, and you are lying about your security". But you are defining the requirements of sips by simply saying that any PBX on the SIP gateway is not secure. Some people would say that the PBX is secure. Maybe a good way around this is for SIP entities to indicate if they came from or went to PSTN. Then people could decide if this was good enough security for the requirements of their call. I still fell sips should be allowed but that sips somehow let the use decide if the security is good enough (just like a user can decide if HTTPS is good enough when the certificate check fails). Attila >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 01 November 2006 20:37 >> To: Attila Sipos >> Cc: IETF SIP List >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >>=20 >>=20 >>=20 >> On Nov 1, 2006, at 5:00 AM, Attila Sipos wrote: >>=20 >> > >> >>> Furthermore, gateways to other protocols not >> >>> offering equally strong protections MUST NOT exercise=20 >> the sips: URI >> >>> scheme. In particular, PSTN gateways MUST NOT use sips:,=20 >> since the >> >>> PSTN itself does not offer equivalent protections and there is no >> >>> ability to determine whether the PSTN segment might be >> >>> converted back to a sip: request somewhere downstream. >> > >> > I don't think you will get agreement on this. >> > >> > I think this rule will have to be very different. Instead >> > of saying that we MUST or MUST NOT, it should be a section >> > on making readers aware of the security implications. >> > In my opinion, it's a policy thing, not a standards thing. >> > >>=20 >> The 2119-language here is in the requirements of practices, not the =20 >> requirements for a protocol design. In short, we're saying "If you =20 >> want to honor the operational requirements of a sips: URI scheme, =20 >> then you MUST NOT downgrade the protection of the signaling to less =20 >> than TLS on any hop. If you do, then you have not met the =20 >> requirements of sips:, and you are lying about your security". In =20 >> short, you are violating the contract of transitive trust. >>=20 >> > There is a benefit in having secure SIP being used upto >> > the PSTN gateway. >> > >>=20 >> Sure. And with the description of sip: URI processing given earlier =20 >> (it will be secured if it can be secured) then sip: gives=20 >> you as good =20 >> of security as you would get by lying about your compliance with =20 >> sips:. So placing a call using a sip: URI to the PSTN gateway would =20 >> produce secure SIP. >>=20 >> -- >> Dean >>=20 >>=20 >>=20 >>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:12:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNLz-0005eH-V6; Wed, 01 Nov 2006 16:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNLx-0005b9-P5 for sip@ietf.org; Wed, 01 Nov 2006 16:10:29 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNLw-00029a-ER for sip@ietf.org; Wed, 01 Nov 2006 16:10:29 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1LAO420982; Wed, 1 Nov 2006 16:10:24 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:10:16 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE86E3@zrc2hxm0.corp.nortel.com> In-Reply-To: <7997E5D5-42B8-42DD-8B8E-9DC1753356C7@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb994hIWRIHmObdQQuH/c45Ck53zwAAkcug From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not saying I'm against your proposal. I'm just saying others may view the "network boundary" to be the IP network. It is a valid opinion. Others may even just view it to be SIP.=20 Even if it sips end-to-end, I can have a bluetooth headset to take the example that Paul K. had. I could duck-tape another phone on my sip phone and do analog coupling.=20 Undetectable. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, November 01, 2006 12:49 PM > To: Audet, Francois (SC100:3055) > Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 > On Nov 1, 2006, at 10:34 AM, Francois Audet wrote: >=20 > > There is a difference however between and SBC and PSTN Gateway, in=20 > > that their security model are quite different. >=20 > How do you know? Specifically, how do you as a UA user on the=20 > SIP side of an SBC, B2BUA, or gateway know? All you have is=20 > trust that the widget honors the contract of sips:. >=20 > Sure, if it's a sips: compliant SBC/B2BUA, it could=20 > reasonably produce sips: on the other side and stay compliant=20 > to the intent of sips:. >=20 > But if it's converting to anything else (sip:, xmpp, ISDN, ISUP, > whatever) it can't maintain the contract of transitive trust=20 > implied by sips:, and it MUST therefore NOT use sips:. >=20 > -- > Dean >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNQz-00088S-VE; Wed, 01 Nov 2006 16:15:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNQy-00088A-Cx for sip@ietf.org; Wed, 01 Nov 2006 16:15:40 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNQw-0003Q9-3J for sip@ietf.org; Wed, 01 Nov 2006 16:15:40 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA1LFWv20926; Wed, 1 Nov 2006 16:15:33 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:15:08 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE86FE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb994hIWRIHmObdQQuH/c45Ck53zwAAkcugAAA8d7A= From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 s/analog/acoustic > I could duck-tape another phone on my sip phone and do analog=20 > coupling.=20 > Undetectable. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNUf-0000ki-5e; Wed, 01 Nov 2006 16:19:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNUd-0000kd-PO for sip@ietf.org; Wed, 01 Nov 2006 16:19:27 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNUc-00045D-EG for sip@ietf.org; Wed, 01 Nov 2006 16:19:27 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8200832LWH2D@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Nov 2006 21:19:29 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG6YQL>; Wed, 01 Nov 2006 21:19:18 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 21:19:16 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: Francois Audet , Juha Heinanen Message-id: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, Well, maybe, but to the extent that I should be denied communication if TLS on all hops cannot be achieved? I think there is an equal case for allowing the request to succeed and reporting the lack of security. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 01 November 2006 21:05 > To: Elwell, John; Juha Heinanen > Cc: Joel M. Halpern; IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > You mean doing IP address spoofing? > > If you don't like impersonation, take theft of service then. > > My point is that I have seen places where signalling security was a > requirement > but not media security. > > It does exist in real life. > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Wednesday, November 01, 2006 12:18 PM > > To: Audet, Francois (SC100:3055); Juha Heinanen > > Cc: Joel M. Halpern; IETF SIP List > > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > > TLS meaning) > > > > Francois, > > > > I disagree. Just securing the signalling is not sufficient to > > prevent impersonation, for example, unless the media is also > > authenticated and integrity protected. As a user, what good > > is it to me if secure signalling tells me that the caller is > > Francois, yet somebody is sending me unsecured media from a > > different source? > > > > I agree that SIPS != padlock. Therefore I am still trying to > > discover real use cases for SIPS. > > > > John > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 01 November 2006 17:12 > > > To: Elwell, John; Juha Heinanen > > > Cc: Joel M. Halpern; IETF SIP List > > > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > > > TLS meaning) > > > > > > > > > > > There are cases where you want signalling to be secure (for > > > > > authentication, impersonation, theft of service, etc.), but > > > > you don't > > > > > need, or want, or even can have encrypted media. > > > > [JRE] No, but you might want authenticated media. It is > all very > > > > well saying that the signalling comes from the person you > > think it > > > > comes from, but if the media is coming from somewhere > else, that > > > > doesn't help the average user. > > > > > > Sure, but it's a different problem. > > > > > > Media security and Signalling security are two different things. > > > > > > SIPS is strictly about hop-by-hop signalling security with TLS. > > > > > > That's why sips != padlock item, otherwise, you'll give a > > false sense > > > of security to the "average user". > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYH-0002GY-S6; Wed, 01 Nov 2006 16:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYF-0002GA-Oj for sip@ietf.org; Wed, 01 Nov 2006 16:23:11 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNYE-0004um-FD for sip@ietf.org; Wed, 01 Nov 2006 16:23:11 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A03D0184; Wed, 01 Nov 2006 16:23:09 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Sanjay Sinha \(\(sanjsinh\)\)'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 16:23:09 -0500 Message-ID: <00bf01c6fdfb$edbcf480$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9+crvJHQXPJbcQW+z9c2qJIyokQAAXNsA X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, November 01, 2006 4:07 PM > > Right. And all of the signaling from SIP is being mapped into some > other signaling protocol and sent beyond a transitive trust boundary. > The gateway simply doesn't know where its goingor what is going to > happen "out there". Consequently, the gateway knows that it cannot > assure transitive trust with respect to signaling integraity, and > since it cannot insure transitive trust, it cannot use sips:. I'm curious: what is it specifically you think you're protecting by using sips, that DOES cross the pstn boundary, and thus would be "leaked"? I mean most of any info that crosses into the pstn is either deducible in sips in some cases too, or doesn't cross, so I'm really curious what it is you think you'd be losing. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYY-0002PE-HA; Wed, 01 Nov 2006 16:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYX-0002P6-U1 for sip@ietf.org; Wed, 01 Nov 2006 16:23:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNYW-0004wM-KW for sip@ietf.org; Wed, 01 Nov 2006 16:23:29 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1KR3Af020903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:27:04 -0600 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4107DB@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670A4107DB@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: tFrom sip-bounces@ietf.org Wed Nov 01 16:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYH-0002GY-S6; Wed, 01 Nov 2006 16:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYF-0002GA-Oj for sip@ietf.org; Wed, 01 Nov 2006 16:23:11 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNYE-0004um-FD for sip@ietf.org; Wed, 01 Nov 2006 16:23:11 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A03D0184; Wed, 01 Nov 2006 16:23:09 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Sanjay Sinha \(\(sanjsinh\)\)'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 16:23:09 -0500 Message-ID: <00bf01c6fdfb$edbcf480$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9+crvJHQXPJbcQW+z9c2qJIyokQAAXNsA X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, November 01, 2006 4:07 PM > > Right. And all of the signaling from SIP is being mapped into some > other signaling protocol and sent beyond a transitive trust boundary. > The gateway simply doesn't know where its goingor what is going to > happen "out there". Consequently, the gateway knows that it cannot > assure transitive trust with respect to signaling integraity, and > since it cannot insure transitive trust, it cannot use sips:. I'm curious: what is it specifically you think you're protecting by using sips, that DOES cross the pstn boundary, and thus would be "leaked"? I mean most of any info that crosses into the pstn is either deducible in sips in some cases too, or doesn't cross, so I'm really curious what it is you think you'd be losing. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYY-0002PE-HA; Wed, 01 Nov 2006 16:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNYX-0002P6-U1 for sip@ietf.org; Wed, 01 Nov 2006 16:23:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNYW-0004wM-KW for sip@ietf.org; Wed, 01 Nov 2006 16:23:29 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1KR3Af020903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:27:04 -0600 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4107DB@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670A4107DB@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C4DE77D-B70D-49C4-A6E2-29F40E754B76@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:23:26 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:03 PM, Elwell, John wrote: > Dean, > > Not quite. See below. > > ... > [JRE] If we have a sips scheme that mandates TLS on all hops > (whatever TLS > might mean) and fails if it can't achieve it, I think there is an > equal > argument for a mechanism that requests TLS on all hops but still > succeeds > and tells me if any hop does not meet this requirement. So if we > recommend > the sip scheme for achieving best effort, it still doesn't tell me > if it > succeeded. Yes, what I want would be a new mechanism, but it would > not be > substantially more difficult to define than the SIPS mechanism. I > am having > a hard time rationalising why we should specify an all-or-nothing > mechanism > (sips) but not a best effort mechanism. In other words I am having > a hard > time understanding the use cases for sips. Maybe the lack of > plausible use > cases is part of the reason it hasn't been deployed much. > So sip: gives us a best effort connection without a reporting mechanism. You want a best-effort connection with a new reporting mechanism. I think that's useful. I also didn't say it was a hard new mechanism to define, just that it's beyond the scope of a BCP to describe. The use case for sips: hasn't changed (except a recommendation for outbound-with-TLS instead of last-hop-excepting ) , and its obvious. One uses sips: only when one is absolutely insistent that each SIP hop be protected by TLS. This is very useful for MESSAGE requests, registrations, presence publications, subscriptions, notifications, and other usages where the SIP payload is the actual communication being protected. It enables key-exchange within SIP for resulting media sessions (although DH is still a better approach). And it helps to obscure the media descriptions, which doesn't protect the media channel directly but does complicate the task of an eavesdropper. There's clearly enough "use case" here for people to be deploying sips: today. Just not enough specification for making those deployments as meaningful as they could be. -- 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 ext/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C4DE77D-B70D-49C4-A6E2-29F40E754B76@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:23:26 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:03 PM, Elwell, John wrote: > Dean, > > Not quite. See below. > > ... > [JRE] If we have a sips scheme that mandates TLS on all hops > (whatever TLS > might mean) and fails if it can't achieve it, I think there is an > equal > argument for a mechanism that requests TLS on all hops but still > succeeds > and tells me if any hop does not meet this requirement. So if we > recommend > the sip scheme for achieving best effort, it still doesn't tell me > if it > succeeded. Yes, what I want would be a new mechanism, but it would > not be > substantially more difficult to define than the SIPS mechanism. I > am having > a hard time rationalising why we should specify an all-or-nothing > mechanism > (sips) but not a best effort mechanism. In other words I am having > a hard > time understanding the use cases for sips. Maybe the lack of > plausible use > cases is part of the reason it hasn't been deployed much. > So sip: gives us a best effort connection without a reporting mechanism. You want a best-effort connection with a new reporting mechanism. I think that's useful. I also didn't say it was a hard new mechanism to define, just that it's beyond the scope of a BCP to describe. The use case for sips: hasn't changed (except a recommendation for outbound-with-TLS instead of last-hop-excepting ) , and its obvious. One uses sips: only when one is absolutely insistent that each SIP hop be protected by TLS. This is very useful for MESSAGE requests, registrations, presence publications, subscriptions, notifications, and other usages where the SIP payload is the actual communication being protected. It enables key-exchange within SIP for resulting media sessions (although DH is still a better approach). And it helps to obscure the media descriptions, which doesn't protect the media channel directly but does complicate the task of an eavesdropper. There's clearly enough "use case" here for people to be deploying sips: today. Just not enough specification for making those deployments as meaningful as they could be. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNZE-0002aH-Ie; Wed, 01 Nov 2006 16:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNZC-0002aC-QR for sip@ietf.org; Wed, 01 Nov 2006 16:24:10 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNZB-00051n-E1 for sip@ietf.org; Wed, 01 Nov 2006 16:24:10 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2006 13:24:09 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="83840626:sNHT51527232" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LO8pK010129; Wed, 1 Nov 2006 13:24:08 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LO8W4026139; Wed, 1 Nov 2006 13:24:08 -0800 (PST) Received: from [171.71.97.119] ([171.71.97.119]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA1LBFOn021528; Wed, 1 Nov 2006 13:11:16 -0800 Message-ID: <4549107D.1000107@cisco.com> Date: Wed, 01 Nov 2006 13:24:13 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> <4548D39F.8050905@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=990; t=1162416248; x=1163280248; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DfUTxn6IgjLQQzti8C+nkZkpuBz4=3D; b=Sv+EtDp9jTjKZYBeMf1CC7sZn+PN3iuOC0tH7Xpi7KMSIv7C//FtqDHKbhFFaXnws39Xqi4K OJ28zXUW4hfot5N/hdQcx3wfjIoi6fj79FUZiNyYIIhMdlTsyoP0bb9J; X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Paul Kyzivat , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 1, 2006, at 11:04 AM, Paul Kyzivat wrote: > >> If you have phone service from a provider that uses SBCs at its >> connection to the internet, when I call "you" I am really calling >> that SBC. All security and authentication properties are with it, >> not you or your devices. I must trust it. The same is true if I call >> a gateway. > > > The point is that you are trusting the SBC to perform in a manner > consistent with the intent of sips:. By accepting the sips: > connection, it has essentially contracted with you to comply with sips:. > > If it does NOT comply with the intent of sips: and translates the > dialog into something that isn't protected and is then "sent out" > beyond its immediate sphere of control (its user interface, if it is > a UA), then it has failed to honor that contract. > Contracted? Heavens. If it's really come to this, we're seriously wrapped around the axle. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNbT-00042V-6k; Wed, 01 Nov 2006 16:26:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyba-0003uk-Sz; Tue, 31 Oct 2006 13:44:59 -0500 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeybW-0006yv-BD; Tue, 31 Oct 2006 13:44:58 -0500 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 8DBEC20A6C8; Tue, 31 Oct 2006 18:44:52 +0000 (UTC) Received: by shell.iptel.org (sSMTP sendmail emulation); Tue, 31 Oct 2006 19:44:50 +0100 Date: Tue, 31 Oct 2006 19:44:50 +0100 From: cco To: "'rohc@ietf.org'" Message-ID: <20061031184450.GS30957@shell> References: <45477421.2080305@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45477421.2080305@nostrum.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 01 Nov 2006 16:26:29 -0500 Cc: SIP WG , Keith Drage , Gonzalo Camarillo , Dean Willis Subject: [Sip] Re: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, Oct 31, 2006 at 10:04:49AM -0600, Adam Roach wrote: > I have been asked to perform a dedicated review on the document > draft-ietf-rohc-sigcomp-sip-03. My comments follow. Note that I have > implemented this specification, any many of my comments arise from > issues I identified during such implementation. > > ------------------------------------------------------------------------ > > I'm having a lot of difficulty parsing the final paragraph in section > 3.2: > > Compressors that make use of initial state memory MUST implement the > SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077]. (Note > that there is no such requirement on decompressors, but see also > Section 6.) For this requirement, initial state memory is defined as > the assumption of a non-zero SMS value before having received an > advertisement of non-zero SMS (e.g., via returned parameters as > specified in section 9.4.9 of [RFC3320]); ANY/SigComp as defined in > [RFC3320] does not have initial state memory. cristian: and this gets even more confusing since at 3.4 we can read: 3.4. SigComp_version (SV) for SIP/SigComp For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. For SIP/SigComp: >= 0x02 (at least SigComp + NACK) > > > There are two separate points of confusion for me: > > 1. I don't understand the assertion that decompressors don't need to > implement RFC 4077. Decompressors serve the critical role of > generating NACK messages when decompression fails. (And, in fact, > text at the end of section 6.3 implies that NACK implementation is > required in decompressors as well). > > 2. The document has already established that stateless compression > (i.e., compression that doesn't take advantage of initial state > memory) is pointless for SIP endpoints -- so the clause > "Compressors that make use of initial state memory" pretty much > collapses to just "Compressors." > > So, unless I've missed something, this paragraph should be rewritten as: > > SIP/SigComp endpoints MUST implement the SigComp Negative > Acknowledgement (NACK) Mechanism [RFC4077]. cristian: I think this should clear everything up; and there should be no doubts on whether NACK should be used or not. since you have already mentioned sipit, here is the experience I have gained from the sigcomp testing done at the last one: clients that use dynamic compression but do not impl. NACK _cannot_ recover from compartment/state mismanagement (which can happen for various reasons either at the proxy or at the client side); clients that implement NACK _do_ recover. bye now! cristian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNd9-0004ql-T6; Wed, 01 Nov 2006 16:28:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHYR-0007Ru-Rt for sip@ietf.org; Wed, 01 Nov 2006 09:58:59 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHYO-00080s-0O for sip@ietf.org; Wed, 01 Nov 2006 09:58:59 -0500 Received: by wx-out-0506.google.com with SMTP id t4so2146472wxc for ; Wed, 01 Nov 2006 06:58:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:x-priority:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=ma08iDmxVaaEWgoExXmM2soKRMp++Qjyw7ZEkACqIgsu7HNDUYoXqm/gOcvMaUGfYI+KlaoS7+aC7Vp8lm0jw8xRzFjmMnobSeMAx/5mBZhUw64LmL5bUo/2NRVX7CgwQ0H3xRTrM+W4etD+voyaOSKd059lOTB37ZFwBAFpe5g= Received: by 10.70.125.2 with SMTP id x2mr9599026wxc; Wed, 01 Nov 2006 06:58:55 -0800 (PST) Received: from ?192.168.1.100? ( [67.191.163.198]) by mx.google.com with ESMTP id i10sm775051wxd.2006.11.01.06.58.54; Wed, 01 Nov 2006 06:58:54 -0800 (PST) In-Reply-To: <000f01c6fdc3$a1069110$030aa8c0@comcast.net> References: <24CCCC428EFEA2469BF046DB3C7A8D221412A8@namail5.corp.adobe.com> <000f01c6fdc3$a1069110$030aa8c0@comcast.net> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B6A6EF9-6B71-4200-B349-B4951CE6F07D@gmail.com> Content-Transfer-Encoding: 7bit From: Ed Pimentel Subject: Re: [p2p-sip] What consensus? (was: What controls the lock icon?(Was RE:[Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 09:58:51 -0500 To: Peter Pan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Wed, 01 Nov 2006 16:28:13 -0500 Cc: sip@ietf.org, p2p-sip@cs.columbia.edu, Henry Sinnreich , Avshalom Houri X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What is missing is the concept of a federated SAML / OpenID / Yadis "iD Provider" Or even an adaptation of what was with H.350 (Internet2.0) but for P2P-SIP Sincerely, -EdPimentl On Nov 1, 2006, at 9:40 AM, Peter Pan wrote: > The disentrance for a secure channel is sweet. It seems to me the > first of > the keypoints that will make P2PSIP win. SIP itself seems never one :( > > Peter > ----- Original Message ----- > From: Henry Sinnreich > To: Avshalom Houri ; sip@ietf.org > Cc: p2p-sip@cs.columbia.edu > Sent: Wednesday, November 01, 2006 5:52 AM > Subject: Re: [p2p-sip] What consensus? (was: What controls the lock > icon?(Was RE:[Sip] RE: TLS meaning)) > > > Avshalom Houri writes: > >> Other then a secure channel or S/MIME I do not think that it will be >> possible to send a SIP message and get real assurance that the >> message >> will be sent securely in every hop. > > As you correctly conclude, P2P SIP has the opportunity to finally > make SIP > secure. > > Thanks, Henry > > > > > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > Sent: Wednesday, November 01, 2006 5:55 AM > To: sip@ietf.org > Subject: Re: What consensus? (was: What controls the lock icon? (Was > RE:[Sip] RE: TLS meaning)) > > > Seems that we need a mechanism to create a trusted "channel" between > endpoints that goes through all the intermediaries. The channel should > verifiable as secure between the endpoints. After the channel is > created > then the SIP signalling can go securely over the channel. > > The protocol for creating such a channel may be SIP based on > external to SIP and after we have such a mechanism we can decide if we > will use SIPS for messages that need to go over the secure channel > or we will use new URI type (e.g. SSIP) or just use some > header in the SIP message. > > The other alternative is the usage of S/MIME which has its > drawbacks as > we can see in another thread. > > Other then a secure channel or S/MIME I do not think that it will be > possible to send a SIP message and get real assurance that the message > will be sent securely in every hop. > > --Avshalom > > > > Dean Willis > 31/10/2006 18:51 ToMichael Thomas > cc"Joel M. Halpern" , "'IETF SIP List'" > , Juha Heinanen , "Elwell, John" > > SubjectRe: What consensus? (was: What controls the lock icon? (Was > RE: [Sip] > RE: TLS meaning)) > > > > > > > > > > On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: > >> My advise to the working group is to just start over from first >> principles as if >> SIPS didn't even exist -- which in reality it doesn't. We need to >> be thinking >> about these things for the long term, and if it's not baked it's >> not baked. There >> have been many drafts that have lingered on and completely >> overhauled over >> the years. Why SIPS is treated so differently in that respect is >> somewhat >> mystifying because dealing with security for SIP is a genuinely >> hard problem. >> It shouldn't be rushed, and it deserves better than a kludgey >> security patina >> airbrushed in to get past the IESG. > > I'm very tempted to endorse this, but I think you're missing one > thing. > > Flimsy as it is, I believe that sips: is as strong as the rest of the > current SIP security model since it depends on the same trust > assumptions. > > We can't just restart on sips: without restarting from those > fundamental trust assumptions. > > This is not trivial. Many people would argue that it would turn SIP > into a fundamentally different protocol. I think it needs to be done, > but I also think we need to clearly document how the current trust > model (including sips:) works, because that's what's going to be > deployed in the real world for a relatively long time. > > The P2PSIP work is having to re-examine those fundamental trust > assumptions. My current hope is we can do some work there that can be > "ported back" into SIP. > > -- > 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 > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNdO-0004wG-Pb; Wed, 01 Nov 2006 16:28:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNdL-0004vS-Tm for sip@ietf.org; Wed, 01 Nov 2006 16:28:27 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNdF-000640-Rb for sip@ietf.org; Wed, 01 Nov 2006 16:28:27 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1KVvjL020966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:31:57 -0600 In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0012A362C@veg-brk-svr-pri.vegastream> References: <8F1F2062CA7D754A838F0E66097D23A0012A362C@veg-brk-svr-pri.vegastream> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FAA0022-0B8D-4DDE-81F3-EAF9E9C896E1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:28:19 -0600 To: "Attila Sipos" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:09 PM, Attila Sipos wrote: >>> In short, we're saying "If you >>> want to honor the operational requirements of a sips: URI scheme, >>> then you MUST NOT downgrade the protection of the signaling to less >>> than TLS on any hop. If you do, then you have not met the >>> requirements of sips:, and you are lying about your security". > > But you are defining the requirements of sips by simply > saying that any PBX on the SIP gateway is not secure. > Some people would say that the PBX is secure. > > Maybe a good way around this is for SIP entities to > indicate if they came from or went to PSTN. > Then people could decide if this was good enough security > for the requirements of their call. > I still fell sips should be allowed but that sips somehow > let the use decide if the security is good enough > (just like a user can decide if HTTPS is good enough > when the certificate check fails). > I don't disagree, but like John Elwell, you appear to be asking for a new reporting mechanism that is beyond the scope of informational or BCP documents to define. If we extended RC 3261 to have the sort of thing you're talking about, then we could change the BCP to take this new mechanism into account. A similar approach can be seen in my existing BCP wording, which basically says "Since outbound gives us a way to overcome the limitation that made the last-hop exception necessary, we now consider it bad practice to use the last-hop exception. Use outbound instead". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNdr-0005Tq-V9; Wed, 01 Nov 2006 16:28:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHDi-00057G-Vt for sip@ietf.org; Wed, 01 Nov 2006 09:37:34 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHDe-0003GX-Ip for sip@ietf.org; Wed, 01 Nov 2006 09:37:34 -0500 Received: from home2000 (c-71-202-22-158.hsd1.ca.comcast.net[71.202.22.158]) by comcast.net (alnrmhc13) with SMTP id <20061101143729b13003nogbe>; Wed, 1 Nov 2006 14:37:30 +0000 Message-ID: <000f01c6fdc3$a1069110$030aa8c0@comcast.net> From: "Peter Pan" To: "Henry Sinnreich" , "Avshalom Houri" , References: <24CCCC428EFEA2469BF046DB3C7A8D221412A8@namail5.corp.adobe.com> Subject: Re: [p2p-sip] What consensus? (was: What controls the lock icon?(Was RE:[Sip] RE: TLS meaning)) Date: Wed, 1 Nov 2006 06:40:07 -0800 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.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-Mailman-Approved-At: Wed, 01 Nov 2006 16:28:58 -0500 Cc: p2p-sip@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The disentrance for a secure channel is sweet. It seems to me the first of the keypoints that will make P2PSIP win. SIP itself seems never one :( Peter ----- Original Message ----- From: Henry Sinnreich To: Avshalom Houri ; sip@ietf.org Cc: p2p-sip@cs.columbia.edu Sent: Wednesday, November 01, 2006 5:52 AM Subject: Re: [p2p-sip] What consensus? (was: What controls the lock icon?(Was RE:[Sip] RE: TLS meaning)) Avshalom Houri writes: >Other then a secure channel or S/MIME I do not think that it will be >possible to send a SIP message and get real assurance that the message >will be sent securely in every hop. As you correctly conclude, P2P SIP has the opportunity to finally make SIP secure. Thanks, Henry From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: Wednesday, November 01, 2006 5:55 AM To: sip@ietf.org Subject: Re: What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning)) Seems that we need a mechanism to create a trusted "channel" between endpoints that goes through all the intermediaries. The channel should verifiable as secure between the endpoints. After the channel is created then the SIP signalling can go securely over the channel. The protocol for creating such a channel may be SIP based on external to SIP and after we have such a mechanism we can decide if we will use SIPS for messages that need to go over the secure channel or we will use new URI type (e.g. SSIP) or just use some header in the SIP message. The other alternative is the usage of S/MIME which has its drawbacks as we can see in another thread. Other then a secure channel or S/MIME I do not think that it will be possible to send a SIP message and get real assurance that the message will be sent securely in every hop. --Avshalom Dean Willis 31/10/2006 18:51 ToMichael Thomas cc"Joel M. Halpern" , "'IETF SIP List'" , Juha Heinanen , "Elwell, John" SubjectRe: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: > My advise to the working group is to just start over from first > principles as if > SIPS didn't even exist -- which in reality it doesn't. We need to > be thinking > about these things for the long term, and if it's not baked it's > not baked. There > have been many drafts that have lingered on and completely > overhauled over > the years. Why SIPS is treated so differently in that respect is > somewhat > mystifying because dealing with security for SIP is a genuinely > hard problem. > It shouldn't be rushed, and it deserves better than a kludgey > security patina > airbrushed in to get past the IESG. I'm very tempted to endorse this, but I think you're missing one thing. Flimsy as it is, I believe that sips: is as strong as the rest of the current SIP security model since it depends on the same trust assumptions. We can't just restart on sips: without restarting from those fundamental trust assumptions. This is not trivial. Many people would argue that it would turn SIP into a fundamentally different protocol. I think it needs to be done, but I also think we need to clearly document how the current trust model (including sips:) works, because that's what's going to be deployed in the real world for a relatively long time. The P2PSIP work is having to re-examine those fundamental trust assumptions. My current hope is we can do some work there that can be "ported back" into SIP. -- 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 _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNeu-0006gX-9H; Wed, 01 Nov 2006 16:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNes-0006fk-TG for sip@ietf.org; Wed, 01 Nov 2006 16:30:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNeq-0006Wv-BF for sip@ietf.org; Wed, 01 Nov 2006 16:30:02 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2006 13:30:00 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="349409998:sNHT57916140" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LTxpf019993; Wed, 1 Nov 2006 13:29:59 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LTxAo019147; Wed, 1 Nov 2006 13:29:59 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 13:29:59 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:29:59 -0800 Message-ID: <454911D6.8080607@cisco.com> Date: Wed, 01 Nov 2006 16:29:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 21:29:59.0179 (UTC) FILETIME=[E1FEB5B0:01C6FDFC] DKIM-Signature: a=rsa-sha1; q=dns; l=4464; t=1162416599; x=1163280599; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DDNy1cmDVaRHP44K+Krww2+YBxpQ=3D; b=DSEzH46kSgOAdpH01Y80EaUTy7ORZ08RKbYlLZhlV6m8H5Cq/KZxoysGLpTgVNwwrG5hAjXi OinkizGoJ0ZjYfXAxzd6GB2oxHrIhMkNF7BjhxOvuSPqCbpByDtnyBLA; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm all for #2 and #3. I'm still pondering whether #1 implies that #2 is useless. On #4, I think this is going to far. Please let us not make the perfect the enemy of the good. I really don't understand why people are placing this absurdly high expectations on what sips can do. As Hadriel pointed out, https only guarantees security to the server; where it got its content from - who knows. -Jonathan R. Dean Willis wrote: > > Ok, let me make a proposal, or perhaps remake one somebody else has > made. I've lost track of who said what... > > I think we're now talking about a BCP for secure operations. > > 1) Implementations of SIP SHOULD use TLS as described in RFC 3261 for > all SIP traffic, including traffic using a sip: URI scheme. Failure to > use TLS may result in disclosure of sensitive signaling information to > third parties. As a matter of local policy, some deployments MAY use > IPSEC or physically protected infrastructure instead of TLS on specific > links. Examples where this might be appropriate include persistent > IPSEC relationships between proxies within an operational domain and > physically protected "private network" cables between a TLS > concentrator and the device it is fronting for. Where TLS is not used, > the implementor MUST exercise a high level of caution to provide > adequate security and MUST preserve operationally equivalent protection > of message integrity, privacy, and participant identity (authentication). > > 2) When using the sips: URI scheme, implementations MUST NOT exercise > the "last hop exception" for sips: processing described in RFC 3261. > Most scenarios where this technique might have seemed appropriate can > be better satisfied using a client-initiated TLS connection as > described in draft-ietf-sip-outbound. User agents that do not implement > both TLS and either terminate TLS connections or exercise > draft-ietf-sip-outbound with a US-originated TOS connection to an > outbound will therefore not be able to exercise the sips: URI scheme. > Failure to observe this requirement is likely to result in a reduction > of operational security below that expected from the sips: URI scheme. > > 3) Since some user-agents will not be able to exercise the sips: > scheme, implementations MUST anticipate the failure of sips: requests > and in general SHOULD use sips: only when it is desired that the > request will not complete unless TLS will be used on each hop. Since > requests using the sip: URI scheme are (by requirement 1 above) > expected to be as securely processed as the implementation is able to > do, it is not suggested that one first try sips: and then back off to > sip:. In other words, if you're willing to settle for the best security > that can actually be provided, simply originate the request with a sip: > URI scheme. > > 4) User agent servers that terminate a request using the sips: URI > scheme MUST create any dependent requests using the sips: URI scheme. > This preserves the commitments of the sips: scheme, and failure to > observe this constraint would give the appearance of sips: security > where no such security exists. For example, this requirement means that > that back-to-back user agents bridging two sips: requests use sips: on > both sides. Furthermore, gateways to other protocols not offering > equally strong protections MUST NOT exercise the sips: URI scheme. In > particular, PSTN gateways MUST NOT use sips:, since the PSTN itself > does not offer equivalent protections and there is no ability to > determine whether the PSTN segment might be converted back to a sip: > request somewhere downstream. > > > -- > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNiT-0000pk-HS; Wed, 01 Nov 2006 16:33:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNiS-0000pU-NR for sip@ietf.org; Wed, 01 Nov 2006 16:33:44 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNiO-0007bQ-NM for sip@ietf.org; Wed, 01 Nov 2006 16:33:44 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1KbEoP021047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:37:15 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE86E3@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DCE86E3@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:33:37 -0600 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:10 PM, Francois Audet wrote: > I could duck-tape another phone on my sip phone and do analog > coupling. > Undetectable. > And if you did, and you used this tape-spliced phone to downgrade from sips: to sip:, then what you would be doing would NOT be a "Best Current Practice". In fact, it would be a violation of the proposed "Best Current Practice" wording. We can't reasonably design useful guns that keep you from deliberately shooting yourself in the head. We can, however, write training manuals that suggest you not do it deliberately, and we can write guidelines like "don't point at something you aren't planning to shoot" that will help keep you from doing it accidentally. Based on the principle of "If it hurts, don't do it", Best Current Practice documents exist to tell people things that are likely to hurt and provide suggestions for alternatives that are expected to hurt less. From that perspective, translating a sips: request to something that is not secured and is likely to be sent somewhere else would also not be a Best Current Practice. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNmG-00027b-Du; Wed, 01 Nov 2006 16:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNmD-0001m0-AV for sip@ietf.org; Wed, 01 Nov 2006 16:37:37 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNmC-00005o-1E for sip@ietf.org; Wed, 01 Nov 2006 16:37:37 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1Kf6wc021083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:41:06 -0600 In-Reply-To: <00bf01c6fdfb$edbcf480$0500a8c0@acmepacket.com> References: <00bf01c6fdfb$edbcf480$0500a8c0@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:37:28 -0600 To: "Hadriel Kaplan" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "'Sanjay Sinha \(\(sanjsinh\)\)'" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:23 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Wednesday, November 01, 2006 4:07 PM >> >> Right. And all of the signaling from SIP is being mapped into some >> other signaling protocol and sent beyond a transitive trust boundary. >> The gateway simply doesn't know where its goingor what is going to >> happen "out there". Consequently, the gateway knows that it cannot >> assure transitive trust with respect to signaling integraity, and >> since it cannot insure transitive trust, it cannot use sips:. > > I'm curious: what is it specifically you think you're protecting by > using > sips, that DOES cross the pstn boundary, and thus would be > "leaked"? I mean > most of any info that crosses into the pstn is either deducible in > sips in > some cases too, or doesn't cross, so I'm really curious what it is > you think > you'd be losing. Given some of the things that can be encoded in QSIG and ISUP and whatnot, I'm sure there's a surprising amount of information that could be leaked. let's ask the converse: If you're engaging in a telephone call that you expect to have sent onto the PSTN, what are you hoping to protect by insisting that the call fail if all the IP signaling links are not wrapped in TLS? Keep in mind that you KNOW that SIP elements compliant to Best Current Practices will encrypt everything that they can possibly encrypt even if you don't use sips: . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNn2-0000jD-8S; Wed, 01 Nov 2006 16:38:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNn0-0000c7-Lj for sip@ietf.org; Wed, 01 Nov 2006 16:38:26 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNmz-0000Ed-BY for sip@ietf.org; Wed, 01 Nov 2006 16:38:26 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1Kf6wd021083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:42:00 -0600 In-Reply-To: <4549107D.1000107@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DCE80F2@zrc2hxm0.corp.nortel.com> <4548D39F.8050905@cisco.com> <4549107D.1000107@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65B09C6C-2EA0-46BE-B5EA-5FCF5F2764E6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:38:23 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List , Paul Kyzivat , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:24 PM, Michael Thomas wrote: > Dean Willis wrote: > >> >> On Nov 1, 2006, at 11:04 AM, Paul Kyzivat wrote: >> >>> If you have phone service from a provider that uses SBCs at its >>> connection to the internet, when I call "you" I am really >>> calling that SBC. All security and authentication properties are >>> with it, not you or your devices. I must trust it. The same is >>> true if I call a gateway. >> >> >> The point is that you are trusting the SBC to perform in a manner >> consistent with the intent of sips:. By accepting the sips: >> connection, it has essentially contracted with you to comply with >> sips:. >> >> If it does NOT comply with the intent of sips: and translates the >> dialog into something that isn't protected and is then "sent out" >> beyond its immediate sphere of control (its user interface, if it >> is a UA), then it has failed to honor that contract. >> > Contracted? Heavens. If it's really come to this, we're seriously > wrapped around > the axle. > ;-) Actually, its the same sort of "contract" that an API or function- call implies. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:42:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNp2-0004DD-HK; Wed, 01 Nov 2006 16:40:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNp1-0004D7-Am for sip@ietf.org; Wed, 01 Nov 2006 16:40:31 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNp0-0000Wo-1u for sip@ietf.org; Wed, 01 Nov 2006 16:40:31 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2006 13:40:29 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="1861350610:sNHT51526500" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LeTE1008962; Wed, 1 Nov 2006 13:40:29 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LeTAo029735; Wed, 1 Nov 2006 13:40:29 -0800 (PST) Received: from [171.71.97.119] ([171.71.97.119]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA1LRamP021897; Wed, 1 Nov 2006 13:27:36 -0800 Message-ID: <45491452.50204@cisco.com> Date: Wed, 01 Nov 2006 13:40:34 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=734; t=1162417229; x=1163281229; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3DGRW9K/sCSuDWaouFDQAw+1n+V/c=3D; b=O7WaQeFBzlfS2w6ZJQAM6ONHokRiPXE84TfqB/9lY4nEBmXjx8LB/Cat2CIAq7PfjbAUsejB MoTwPSD2OxuDfbKw2wLywF5wT4lGBg5ingl3f209cd4Nvel8spdvSRIN; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: >Francois, > >Well, maybe, but to the extent that I should be denied communication if TLS >on all hops cannot be achieved? I think there is an equal case for allowing >the request to succeed and reporting the lack of security. > > > Right. What's being lost in all of this is that receiver's ought to have some say in all of this too. SIP is a rendezvous protocol, after all. To the extent that SIP can affect that rendezvous and let the participants make an informed decision, that seems like the right direction. Mike PS: is there any sort of notion of adding the transport protection information in Via's like, oh say, sendmail does with Received headers with TLS? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNrv-0005pW-NC; Wed, 01 Nov 2006 16:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNru-0005pE-Ge for sip@ietf.org; Wed, 01 Nov 2006 16:43:30 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNrt-0001CQ-6y for sip@ietf.org; Wed, 01 Nov 2006 16:43:30 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1Kl3d1021132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:47:04 -0600 In-Reply-To: <454911D6.8080607@cisco.com> References: <454911D6.8080607@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 15:43:26 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:29 PM, Jonathan Rosenberg wrote: > I'm all for #2 and #3. I'm still pondering whether #1 implies that > #2 is useless. > > On #4, I think this is going to far. Please let us not make the > perfect the enemy of the good. I really don't understand why people > are placing this absurdly high expectations on what sips can do. As > Hadriel pointed out, https only guarantees security to the server; > where it got its content from - who knows. > #4 says: >> 4) User agent servers that terminate a request using the sips: >> URI scheme MUST create any dependent requests using the sips: URI >> scheme. This preserves the commitments of the sips: scheme, and >> failure to observe this constraint would give the appearance of >> sips: security where no such security exists. For example, this >> requirement means that that back-to-back user agents bridging two >> sips: requests use sips: on both sides. Furthermore, gateways to >> other protocols not offering equally strong protections MUST NOT >> exercise the sips: URI scheme. In particular, PSTN gateways MUST >> NOT use sips:, since the PSTN itself does not offer equivalent >> protections and there is no ability to determine whether the PSTN >> segment might be converted back to a sip: request somewhere >> downstream. Without #4, then any SBC can use sips: on one side and sip: on the other and nobody will know that it's broken. In fact, we'd have documented doing so as being consistent with Best Current Practice. Is that what you want? The way I read it, #1 makes #4 acceptable. After all, you're going to get best possible security from sip: from #1 You only use sips: if you want the call to fail if it is not possible for EVERY hop to use TLS. So if you expect to gateway the call, use sip:, not sips:. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNuD-00084z-9J; Wed, 01 Nov 2006 16:45:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNuB-00083j-WD for sip@ietf.org; Wed, 01 Nov 2006 16:45:52 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNuA-00021E-Ma for sip@ietf.org; Wed, 01 Nov 2006 16:45:51 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1KnPDK021153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 14:49:25 -0600 In-Reply-To: <45491452.50204@cisco.com> References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> <45491452.50204@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Wed, 1 Nov 2006 15:45:48 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:40 PM, Michael Thomas wrote: > PS: is there any sort of notion of adding the transport protection > information in Via's > like, oh say, sendmail does with Received headers with TLS? yep, that's one way to get the "What happened downstream" info back so the nodes can operate under "informed consent". Of course, the SBCs that we're worried about breaking sips: also tend to hide the Via header fields, so it might not be all that useful. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:53:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNzq-0001ox-6p; Wed, 01 Nov 2006 16:51:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNzo-0001ok-HR for sip@ietf.org; Wed, 01 Nov 2006 16:51:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNzm-00034W-G2 for sip@ietf.org; Wed, 01 Nov 2006 16:51:40 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2006 13:51:38 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="83855805:sNHT47864754" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LpbIF030809; Wed, 1 Nov 2006 13:51:37 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LpbAo012950; Wed, 1 Nov 2006 13:51:37 -0800 (PST) Received: from [171.71.97.119] ([171.71.97.119]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA1LciIk022145; Wed, 1 Nov 2006 13:38:45 -0800 Message-ID: <454916EE.5050105@cisco.com> Date: Wed, 01 Nov 2006 13:51:42 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> <45491452.50204@cisco.com> <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> In-Reply-To: <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=706; t=1162417897; x=1163281897; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3DGRW9K/sCSuDWaouFDQAw+1n+V/c=3D; b=AGV8SMJu10V4A+cAybinA5Qy/YIJOADHMlK9nE3pbe/clflK6nBjywfgFeuYgNYt2rfnpnOy qnued4Gsyc2Qao1bdOQ8Bwjp0XZIa/FYPPe0kkqgYoiBlu71mmQQfjWA; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 1, 2006, at 3:40 PM, Michael Thomas wrote: > >> PS: is there any sort of notion of adding the transport protection >> information in Via's >> like, oh say, sendmail does with Received headers with TLS? > > > yep, that's one way to get the "What happened downstream" info back > so the nodes can operate under "informed consent". Ok. Is it possible to put Via's in the reverse direction? Or some other way to inform the originator of the forward/backward transport path's protection characteristics? If so, wouldn't that do pretty much everything you want SIPS to do without the unappealing all-or-nothing problems of SIPS? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 16:58:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfO4c-0003gf-1P; Wed, 01 Nov 2006 16:56:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfO4a-0003fP-4B for sip@ietf.org; Wed, 01 Nov 2006 16:56:36 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfO4S-0003rT-MA for sip@ietf.org; Wed, 01 Nov 2006 16:56:36 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E8084DB9; Wed, 1 Nov 2006 22:56:25 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 22:56:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Nov 2006 22:50:31 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB594045FF56C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Editorial comments on draft-rosenberg-sip-outbound-discovery-mid-dialog-00 Thread-Index: Acb9/8B1CYkcIwFfSRejFB+PiSsapw== From: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" , "Jonathan Rosenberg" X-OriginalArrivalTime: 01 Nov 2006 21:56:25.0745 (UTC) FILETIME=[93A97810:01C6FE00] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Sip] Editorial comments on draft-rosenberg-sip-outbound-discovery-mid-dialog-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Some editorial comments on the first parts of the draft. Chapter 1. ---------- Q1. The text says: "SIP-outbound also provides a keepalive mechanism, utilizing the Simple Traversal Underneath NAT (STUN) [5]," I think we should say that "SIP-outbound also USES a keepalive mechanism, utilizing...", since STUN keepalive is not part of the SIP-outbound mechanism. Q2. The text, when referring to SIP-outbound, you mostly use outbound proxy wording. I think it would be good to say that it corresponds to what SIP-outbound calls edge proxy - or to use edge proxy also in this draft. Currently edge proxy wording is used in Req-2 and in chapter 9. Chapter 2. ---------- Q3. In requirement 4, I guess the IMS IBCF could also be mentioned. An IBCF will most likely Record-Route, while an I-CSCF may not always. Chapter 3. ---------- Q4. Should we put the basic outbound discovery text into the SIP-outbound draft (I think Juha also asked this question earlier)? Q5. As part of the outbound discussion, I've argued that an UA should not be mandated to establish flows through all edge proxies it is aware of. So, the question is whether an UA MUST establish flows through each proxy listed in the Alternative-Proxies. As part of the outbound discussion I have also proposed the possibility for the network to indicate in the REGISTER response how many flows the UA should establish. I think that would be useful also together with Alternative-Proxies. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 17:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOA7-0007rz-J8; Wed, 01 Nov 2006 17:02:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOA6-0007rm-GJ for sip@ietf.org; Wed, 01 Nov 2006 17:02:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOA5-00058H-4C for sip@ietf.org; Wed, 01 Nov 2006 17:02:18 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2006 14:02:16 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="338383783:sNHT53294072" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1M2GKD012705; Wed, 1 Nov 2006 14:02:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1M2GAo026005; Wed, 1 Nov 2006 14:02:16 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 14:02:16 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:02:16 -0800 Message-ID: <45491967.6070609@cisco.com> Date: Wed, 01 Nov 2006 17:02:15 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt References: <5D1A7985295922448D5550C94DE2918065EA37@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918065EA37@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 22:02:16.0126 (UTC) FILETIME=[64815DE0:01C6FE01] DKIM-Signature: a=rsa-sha1; q=dns; l=2054; t=1162418536; x=1163282536; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Request=20for=20views=20on=09draft-drage-sip-essential-c orrection-00.txt; X=v=3Dcisco.com=3B=20h=3DrjiHp1vZJqmnoiTGuza3QKcUNSw=3D; b=nxzXqVQ/LJjQitnJQVxWS3tqwN5NBdj9JaJdmt/qHNtRgBCC+XwXNlWx6n0YmI5ghPOXICkK 6deE7S70HGXj6yW6i17bVXL8o0xHla70vSaI1dNMaRFieEfr54PHYkzM; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, I agree with the final step here, but I'm not so sure about your details of the intermediate steps. In particular, I think it is too onerous to require one I-D per issue. FOr example it would be nice for someone to go through the bugzilla database and submit one I-D with all of the things in it that we need to put into the corrections spec. THis is more palatable than having to submit 30 separate documents, each 6 pages in length (5.5 pages overhead and 1/2 page for the useful content). Also we need to discuss what happens when more bugs get reported after the correction RFC is published. DO we revise that RFC? Or issue another corrections document? -Jonathan R. Drage, Keith (Keith) wrote: > I have recently submitted > > http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction > -00.txt > > The idea behind this draft, is to put some management into getting real > bugfixes: > > - into one place where people can find it > - give it standards track RFC status so that people know they have > to implement it. > > If people not already consulted have views on this process, then please > let them be known. > > The idea would be to start this process (taking into account any input > from the WG) after the next IETF meeting. > > Regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 17:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOSq-0006pe-Qp; Wed, 01 Nov 2006 17:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOSp-0006lZ-6W for sip@ietf.org; Wed, 01 Nov 2006 17:21:39 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOSm-0008Qu-RF for sip@ietf.org; Wed, 01 Nov 2006 17:21:39 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfOSn-00037H-Ji; Wed, 01 Nov 2006 16:21:37 -0600 From: "Brian Rosen" To: "'Francois Audet'" , "'Dean Willis'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 17:21:20 -0500 Message-ID: <011201c6fe04$10945a40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb994hIWRIHmObdQQuH/c45Ck53zwAAkcugAAJcMYA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE86E3@zrc2hxm0.corp.nortel.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "'Sanjay Sinha \(\(sanjsinh\)\)'" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Let's take your examples. First was Bluetooth. I agree this is a judgment call, but because I think we're all thinking the same thing: the phone is the phone is the phone and it's not the headset, I think it's not in the signaling path. Now you want to talk about acoustic coupling. I think that one is easy. If both sides of the coupling are TLS end to end, then you have a poor man's B2BUA and the sips sticker is awarded. If one or the other side does not maintain TLS end to end, it doesn't meet Dean's words. I don't think there is much of a judgment there. Dean's proposal DOES admit to judgment calls. It's not perfect, but it's useful. Brian > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, November 01, 2006 4:10 PM > To: Dean Willis > Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > I'm not saying I'm against your proposal. > > I'm just saying others may view the "network boundary" to be > the IP network. It is a valid opinion. > > Others may even just view it to be SIP. > > Even if it sips end-to-end, I can have a bluetooth headset to take the > example that Paul K. had. > > I could duck-tape another phone on my sip phone and do analog coupling. > Undetectable. > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, November 01, 2006 12:49 PM > > To: Audet, Francois (SC100:3055) > > Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > > > > On Nov 1, 2006, at 10:34 AM, Francois Audet wrote: > > > > > There is a difference however between and SBC and PSTN Gateway, in > > > that their security model are quite different. > > > > How do you know? Specifically, how do you as a UA user on the > > SIP side of an SBC, B2BUA, or gateway know? All you have is > > trust that the widget honors the contract of sips:. > > > > Sure, if it's a sips: compliant SBC/B2BUA, it could > > reasonably produce sips: on the other side and stay compliant > > to the intent of sips:. > > > > But if it's converting to anything else (sip:, xmpp, ISDN, ISUP, > > whatever) it can't maintain the contract of transitive trust > > implied by sips:, and it MUST therefore NOT use sips:. > > > > -- > > 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 sip-bounces@ietf.org Wed Nov 01 17:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOYs-0000W9-Qh; Wed, 01 Nov 2006 17:27:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOYs-0000W4-2I for sip@ietf.org; Wed, 01 Nov 2006 17:27:54 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOYq-0001Np-0R for sip@ietf.org; Wed, 01 Nov 2006 17:27:53 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA1LVKaX021453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2006 15:31:20 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP List Message-Id: From: Dean Willis Date: Wed, 1 Nov 2006 16:27:42 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012 Cc: Cullen Jennings , Keith Drage , "Vijay K. Gurbani" , "James M. Polk" Subject: [Sip] Revised SIP agenda, IETF 67 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0142868857==" Errors-To: sip-bounces@ietf.org --===============0142868857== Content-Type: multipart/alternative; boundary=Apple-Mail-4--570731217 --Apple-Mail-4--570731217 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The SIP agenda has been revised to account for a couple of things: 1) We overlap with TLS on Friday, so we swapped all the stuff requiring EKR to Thursday. This resulted in much juggling, and I'm just about as irritated as a bobcat in a clothesdryer. 2) I had incorrectly anticipated new versions of identity-coexistence and diagnostic responses, so I've updated the reading list to point at what I think are current versions. HTML version of agenda follows: Draft Agenda, SIP at IETF 67 Session 1: Thursday 1300-1500 Grand Ballroom C Time Topic Discussion leaders Reading List 1300 Agenda Bash and Status Chairs this document 1305 Outbound Rohan Mahy draft-ietf-sip-outbound-05 1325 Domain Certs and Connection Reuse Vijay Gurbani draft-gurbani-sip-domain-certs-03 draft-ietf-sip-connect-reuse-07 1 1345 SIPS Guidelines Francois Audet draft-audet-sip-sips-guidelines-04 1415 GRUU and Supporting Drafts Jonathan Rosenberg draft-ietf-sip-gruu-11 draft-rosenberg-sip-ua-loose-route-00 Session 2: Friday 0900-1130 Grand Ballroom C Time Topic Discussion leaders Reading List 0900 Agenda Bash Chairs This Document 0905 Location Conveyance James Polk Brian Rosen draft-ietf-sip-location-conveyance-05 0925 Connected Identity John Elwell draft-ietf-sip-connected-identity-02 0950 Identity Coexistence Jonathan Rosenberg draft-rosenberg-sip-identity-coexistence-00 1010 Outbound Discovery and Mid-Dialog requests Jonathan Rosenberg draft-rosenberg-sip-outbound-discovery-mid-dialog-00 1030 Diagnostic Responses Scott Lawrence Vijay Gurbani draft-ietf-sip-hop-limit-diagnostics-03 draft-gurbani-sip-large-udp-response-00 1050 UA Profile Delivery Dan Petrie draft-ietf-sip-xcap-config-00 1115 Jonathan Rosenberg Route Constuction draft-rosenberg-sip-route-construct-02 --Apple-Mail-4--570731217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

The SIP agenda has been = revised to account for a couple of things:

1) We overlap with TLS on = Friday, so we swapped all the stuff requiring EKR to Thursday. This = resulted in much juggling, and I'm just about as irritated as a bobcat = in a clothesdryer.

2) I had incorrectly = anticipated new versions of identity-coexistence and diagnostic = responses, so I've updated the reading list to point at what I think are = current versions.


HTML version of agenda = follows:

Draft Agenda, = SIP at IETF 67



Session 1: = Thursday 1300-1500 Grand Ballroom C


1325
<= /TR>
Time
Topic
Discussion leaders
Reading = List
1300
Agenda Bash and Status
Chairs
this = document
1305
Outbound
Rohan Mahy
Domain Certs and=A0
Connection = Reuse
Vijay Gurbani
1345
SIPS Guidelines
Francois Audet
1415
GRUU and Supporting = Drafts
Jonathan Rosenberg


Session 2: = Friday 0900-1130 Grand Ballroom C


<= /TR>= =
Time
Topic
Discussion leaders
Reading = List
0900
Agenda Bash
Chairs
This Document
0905
Location = Conveyance
James Polk
Brian = Rosen
0925
Connected = Identity
John Elwell
0950
Identity = Coexistence
Jonathan Rosenberg
=
1010
Outbound Discovery=A0
and Mid-Dialog requests
Jonathan = Rosenberg
1030
Diagnostic Responses
Scott Lawrence
Vijay = Gurbani
draft-gurbani-sip-large-udp-response-00
1050
UA Profile = Delivery
Dan Petrie
1115
Jonathan = Rosenberg
Route Constuction

References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> <45491452.50204@cisco.com> <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> <454916EE.5050105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E27C36F-2349-41EE-815E-A7E46010D812@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Wed, 1 Nov 2006 16:41:50 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 1, 2006, at 3:51 PM, Michael Thomas wrote: > Dean Willis wrote: > >> >> On Nov 1, 2006, at 3:40 PM, Michael Thomas wrote: >> >>> PS: is there any sort of notion of adding the transport >>> protection information in Via's >>> like, oh say, sendmail does with Received headers with TLS? >> >> >> yep, that's one way to get the "What happened downstream" info >> back so the nodes can operate under "informed consent". > > > Ok. Is it possible to put Via's in the reverse direction? Or some > other way to inform > the originator of the forward/backward transport path's protection > characteristics? > History-Info, RFC 4244 is something like this. We're a little short on implementations so far, but I think it could be reasonably adapted to provide change-of-crypto "retargeting" info. > If so, wouldn't that do pretty much everything you want SIPS to do > without the > unappealing all-or-nothing problems of SIPS? With the exception that you'd get an established dialog (or a MESSAGE request delivered) that has an unsecured connection in it, then say "oops". Here's a legit use case for sips: I want to send you a text message with moderately sensitive info. So I send it using your sips: request URI. If it turns out that a proxy out there can't honor that request for transitive protection, it rejects the request rather than exposing my sensitive text-bits to the harsh climes of an unencrypted channel. So I still need that "I want it" part of sips. With just a post-facto diagnostic (like History-Info) I'd have to first establish a dialog, then look and see if I liked the security, then send a MESSAGE over that dialog (considered to be abusing the dialog by the MESSAGE RFC), then tear the dialog down. But your proposal works great for the use case John and others have come up with -- "Ok, I've got a dialog. Now how am I going to use 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 sip-bounces@ietf.org Wed Nov 01 18:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPDU-0004cv-FX; Wed, 01 Nov 2006 18:09:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPDT-0004cn-2v for sip@ietf.org; Wed, 01 Nov 2006 18:09:51 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPDR-0000mK-Qk for sip@ietf.org; Wed, 01 Nov 2006 18:09:51 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A93A06A8; Wed, 01 Nov 2006 18:09:46 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Wed, 1 Nov 2006 18:09:45 -0500 Message-ID: <00e801c6fe0a$d249ae50$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9/e/l9WvO4irwRuiHuRaOkWb7TAAAIAXg X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "'Sanjay Sinha \(\(sanjsinh\)\)'" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, November 01, 2006 4:37 PM > > Given some of the things that can be encoded in QSIG and ISUP and > whatnot, I'm sure there's a surprising amount of information that > could be leaked. Indeed, but as I understand it unless it was already in an ISUP/QSIG attachment in sips, most of the info that would be generated is not from sip itself but defaults, or could be deduced by a sips session traffic as well (without seeing inside). For some cases, anyway. And if the ISUP/QSIG info _is_ in the sips to begin with, then clearly it came from or knows it is going to the pstn. > let's ask the converse: If you're engaging in a telephone call that > you expect to have sent onto the PSTN, what are you hoping to protect > by insisting that the call fail if all the IP signaling links are not > wrapped in TLS? Keep in mind that you KNOW that SIP elements > compliant to Best Current Practices will encrypt everything that they > can possibly encrypt even if you don't use sips: . . . That's not the only converse, and I personally wouldn't send it as sips, but for that question someone's answer could be: I would be using sips to protect my sdesc keys for srtp, because I feel it is easier to remotely monitor/harvest/etc. traffic on the public Internet than on the pstn, and I want the media secured. So I want it to fail so I know to speak in pig-latin, or not type my pin code, or whatever. I may have typed in a sips:joe.dirt@kxla.com, but if it got retargeted to his cell through a provider staying sips I don't expect them to reject the request just because I am using sips and it would go across the pstn. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 18:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPHf-0007ra-WC; Wed, 01 Nov 2006 18:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPHe-0007rU-HA for sip@ietf.org; Wed, 01 Nov 2006 18:14:10 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPHd-0001Rb-8N for sip@ietf.org; Wed, 01 Nov 2006 18:14:10 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA1N7Gh15863; Wed, 1 Nov 2006 18:07:17 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Wed, 1 Nov 2006 17:14:05 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DD3CC12@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb9+2fxWP2/KVzVTo2Z3+iL3pX0zAAD4ZBw From: "Francois Audet" To: "Elwell, John" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Joel M. Halpern" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Well, maybe, but to the extent that I should be denied=20 > communication if TLS on all hops cannot be achieved?=20 Yes. I will argue that some may want to do that. Correct. > I think=20 > there is an equal case for allowing the request to succeed=20 > and reporting the lack of security. I agree that some may want to do that as well. That's my whole point: sips means what it means. It doesn't mean media security, it doesn't mean "Security-with-a-capital-S", it=20 doesn't mean some icon to be displayed to the user. It just means the hop-by-hop TLS thing that we talked about. If that is useful for your application, use it. If it is not, then don't use it. If it is useful only in conjunction with other security mechanism (e.g., media security), then do that to. We are not doing product design here. We are doing bits on the wire. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 01 18:24:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPOz-00075M-4x; Wed, 01 Nov 2006 18:21:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPOx-00075H-OR for sip@ietf.org; Wed, 01 Nov 2006 18:21:43 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPOv-0002it-4s for sip@ietf.org; Wed, 01 Nov 2006 18:21:43 -0500 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA1NLQ722209; Wed, 1 Nov 2006 16:21:26 -0700 Message-ID: <45492BF6.90706@ntt-at.com> Date: Wed, 01 Nov 2006 15:21:26 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] New I-D on UA loose routing References: <452FC0B7.6030007@cisco.com> <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <4541343D.3080908@cisco.com> <953beacc0610300721x513a8296gf70df33d2eca2afb@mail.gmail.com> In-Reply-To: <953beacc0610300721x513a8296gf70df33d2eca2afb@mail.gmail.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Both Brian's and your proposal concerns me a bit. Although, I may simply be confused about all this. AFAIK grid is only meaningful to the entity that provided the grid in the first place(UA that provided the grid in the Contact, conference server etc.). Imagine a scenario below. 1. Alice receives a call from Bob's home phone and ua-opaque is used to identify each family member's phone in Bob's household(sub-addresing). 2. Contact Alice receives in the INVITE has Bob@b.com;ua-opaque=steve 3. Alice later calls Bob using the call-log but call is redirected to Carol's house who is Bob's sister. 4. So R-URI is rewritten from Bob@b.coim;ua-opaque=steve to Carol@c.com;ua-opaque=steve if the ua-opaque is retained through retargeting as you suggested. 5. If Carol's house has steve as a family member and uses ua-opaque to address each family members as Bob's house, call will be routed towards Steve. Now, there may be no problems with the outcome mentioned above, but I really don't know if this is the kind of behavior we want. Also the solution mentioned below will only address one of the issues loose-route is trying to address(Retaining opaque value through AoR to contact translation). The loose-route AFAIU also tries to retain the original request target(AoR), which your solution does not address.(Although I question why p-called-party-id can't be used to address this issue) Lastly I don't agree with having GRUU dependent on ua-opaque or grid like mechanism. They both address different issues. GRUU has its place, and grid or ua-opaque also has its place but I see no reason to necessitate dependencies. Regards Shida Rohan Mahy wrote: > Hi, > > First I'd like to propose a concrete counter proposal. Dean would > call this an additional "band-aid" but I feel like the patient has > painfully managed to recover pretty well from 2nd degree burns over > 60% of the body and now just has a persistent paper cut. > > We define a new URI parameter called 'ua-opaque'. When an > authoritative proxy receives a request with this parameter in the > request URI (in an AOR or a GRUU), it copies the value of this > parameter into any URI it retargets to. This functionality is > mandatory for URIs which are GRUU. This parameter effectively > replaces the 'grid' parameter by providing a simple superset of the > functionality. > > I believe that this approach has significantly better backwards > compatility and maturity than the UA loose-route approach. Below I > will list the technical problems I see with the UA loose route > approach. > > 1) Outbound. the current outbound draft has language about what the > first edge proxy needs to do. One of the ways to tell if the first > proxy did its job is to check the first element in the Path vector for > the 'ob' parameter. I don't believe this would work anymore. Maybe I > am not smart enough, but I can't think of a way to make detection that > outbound will work in a UA loose-route environment, short of a > first-hop Proxy-Require, which a number of folks where adamantly > against. > > 2) Forking / HERFP. There are some UAs which reject requests to them > with Route headers left with a 400 and some with a 403. To be safe, a > proxy will need to forward in the traditional manner to > non-loose-route UAs, or risk exacerbating HERFP. A proxy forking to > both UA loose-route and non-UA loose UAs therefore needs to keep track > of both and effectively run two separate code paths for different > branches for the same target set. > > 3) Marid-style assumptions. Like the problem with outbound, a proxy > that wants to check that requests are either for its domain or from > its domain and that it is receiving requests for its domain directly > (not through an intervening proxy) may have a harder time figuring out > if it is the first proxy. > > thanks, > -rohan > > > On 10/26/06, Jonathan Rosenberg wrote: >> You are equating processing a Route header, with being a proxy. Nothing >> in RFC 3261 says that if you process a Route header, you are a proxy. >> Indeed, RFC 3261 is silent on the applicability of Route headers to UA. >> Certainly I agree we don't want to require a UA to do thigns like mutual >> TLS. >> >> Indeed, I would like to understand what concrete problems you see. Your >> note points out that there could be other solutions, and then complains >> that this is making things confusing. Yes, there could be other >> solutions - I look forward to your draft. I don't think it makes things >> more confusing. >> >> I think this mechanism is quite elegant in that extends the idea of >> loose routing to UA, and is arguably what we should have done in SIP in >> the first place. >> >> -Jonathan R. >> >> >> >> >> >> Rohan Mahy wrote: >> >> > Hi, >> > >> > I have read this draft and I think it is a terrible idea in SIP/2.0 to >> > send a UA an incoming request with a Route header. If we were working >> > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea >> > to consider as baseline behavior, but I think this is too major of a >> > change from the current spec and state of implementation. >> > >> > Lets analyze the requirements described in the document. The unkown >> > gruu, limited-use gruu, subaddressing, and service invocation >> > requirements can all be met just by restoring the grid parameter to >> > its rightful place in GRUU. The emergency services requirement is a >> > tautology; if a proxy wants to rewrite the Request-URI from an SOS >> > URN, don't do that, insert a loose-route instead; no additional >> > mechanism or specification is necessary. The freephone requirement >> > deals with mixed SIP and PSTN networks, where the existing >> > History-Info (or dare I say Diversion) mechanism is perfectly adequate >> > and more likely to be implemented in this environment. The alias >> > requirement can be addresses in a variety of ways including >> > configuration, or simply restoring the To header to usefulness. My >> > conclusion is that this mechanism does not solve any requirements we >> > are not already addressing. (If we were starting from scratch, we >> > might do things differently). >> > >> > As for the implications of handling loose-routing on the UA, I do not >> > believe the expected behavior is easily containable. The only entities >> > that should receive requests with additional Route headers are proxy >> > servers. Embedding a proxy server in/on a UA then requires the UA to >> > implement TLS, strict route fix ups, loop detection, and a host of >> > other things. I don't think we want to go there. The alternative is >> > for us to break the rules and define a "sort of a proxy" role. I >> > expect picking apart what parts of RFC3261 need to be implemented as a >> > proxy would be a nightmare. I can also imagine the impact on the >> > outbound draft if each outbound UA needs to route through an embeded >> > edge proxy. How will the first "real" edge proxy decide if outbound >> > processing has been done correctly? >> > >> > The concept of logical roles such as proxy, registrar, identity >> > server, etc. is already confusing to many implementors. If we start >> > redefining or breaking the rules which describe existing roles, I >> > believe we are going to have a real mess on our hands. >> > >> > thanks, >> > -rohan >> > >> > >> > >> > On 10/13/06, Jonathan Rosenberg wrote: >> > >> >> I've submitted a new I-D which describes this concept of UA loose >> >> routing that we've been discussing on the list. This fell out of the >> >> GRUU discussions as an alternative solution for grid. As the draft >> >> explains, the mechanism also solves many other problems, like >> >> sub-addressing, limited use adresses, 8xx number usage, and is even >> >> required for proper 911/emergency services operation with ecrit. >> >> >> >> Until the draft appears in the archives, you can pick it up at: >> >> >> http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt >> >> >> >> Thanks, >> >> Jonathan R. >> >> -- >> >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> >> Cisco Fellow Parsippany, NJ 07054-2711 >> >> Cisco Systems >> >> jdrosen@cisco.com FAX: (973) 952-5050 >> >> http://www.jdrosen.net PHONE: (973) 952-5000 >> >> http://www.cisco.com >> >> >> >> _______________________________________________ >> >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP Protocol >> >> Use sip-implementors@cs.columbia.edu for questions on current sip >> >> Use sipping@ietf.org for new developments on the application of sip >> >> >> > >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 02:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAk-0000gS-5K; Thu, 02 Nov 2006 02:39:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAg-0000b9-NG for sip@ietf.org; Thu, 02 Nov 2006 02:39:31 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfX50-0004fh-R8 for sip@ietf.org; Thu, 02 Nov 2006 02:33:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA27X6t20902; Thu, 2 Nov 2006 02:33:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 01:33:09 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875DF@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE86FE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb994hIWRIHmObdQQuH/c45Ck53zwAAkcugAAA8d7AAFXnTIA== From: "Samir Srivastava" To: "Francois Audet" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You can cut the vegetables etc by knife and nobody stops you cutting the neck... This is endless debate on meaning of security ? Thx Samir=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Wednesday, November 01, 2006 1:15 PM To: Dean Willis Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List Subject: RE: [Sip] A sips: trial balloon for you to shoot down =20 s/analog/acoustic > I could duck-tape another phone on my sip phone and do analog=20 > coupling. > Undetectable. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 02:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAt-0000tT-JT; Thu, 02 Nov 2006 02:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAs-0000mx-Fy for sip@ietf.org; Thu, 02 Nov 2006 02:39:42 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfWyL-0003iH-Eu for sip@ietf.org; Thu, 02 Nov 2006 02:26:46 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA27QcF26063; Thu, 2 Nov 2006 02:26:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version:From sip-bounces@ietf.org Thu Nov 02 02:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAk-0000gS-5K; Thu, 02 Nov 2006 02:39:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAg-0000b9-NG for sip@ietf.org; Thu, 02 Nov 2006 02:39:31 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfX50-0004fh-R8 for sip@ietf.org; Thu, 02 Nov 2006 02:33:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA27X6t20902; Thu, 2 Nov 2006 02:33:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 01:33:09 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875DF@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DCE86FE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb994hIWRIHmObdQQuH/c45Ck53zwAAkcugAAA8d7AAFXnTIA== From: "Samir Srivastava" To: "Francois Audet" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Sanjay Sinha \(\(sanjsinh\)\)" , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You can cut the vegetables etc by knife and nobody stops you cutting the neck... This is endless debate on meaning of security ? Thx Samir=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Wednesday, November 01, 2006 1:15 PM To: Dean Willis Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List Subject: RE: [Sip] A sips: trial balloon for you to shoot down =20 s/analog/acoustic > I could duck-tape another phone on my sip phone and do analog=20 > coupling. > Undetectable. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 02:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAt-0000tT-JT; Thu, 02 Nov 2006 02:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAs-0000mx-Fy for sip@ietf.org; Thu, 02 Nov 2006 02:39:42 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfWyL-0003iH-Eu for sip@ietf.org; Thu, 02 Nov 2006 02:26:46 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA27QcF26063; Thu, 2 Nov 2006 02:26:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Thu, 2 Nov 2006 01:26:41 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875DE@zrc2hxm2.corp.nortel.com> In-Reply-To: <454916EE.5050105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb+ACxastq7GylFQeOM0Q8XT/bEeAAT25JA From: "Samir Srivastava" To: "Michael Thomas" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Mike, My cipher-suite draft proposes the reverse channel for this purpose. http://www.ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuite s-00.txt The proposal in 3.D is sending back the least valued used cipher-suite, but the group including EKR, agreed to send back the complete via header. Thx Samir =20 >Ok. Is it possible to put Via's in the reverse direction? Or some other >way to inform >the originator of the forward/backward transport path's protection=20 >characteristics? >If so, wouldn't that do pretty much everything you want SIPS to do=20 >without the >unappealing all-or-nothing problems of SIPS? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Thu, 2 Nov 2006 01:26:41 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875DE@zrc2hxm2.corp.nortel.com> In-Reply-To: <454916EE.5050105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb+ACxastq7GylFQeOM0Q8XT/bEeAAT25JA From: "Samir Srivastava" To: "Michael Thomas" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Mike, My cipher-suite draft proposes the reverse channel for this purpose. http://www.ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuite s-00.txt The proposal in 3.D is sending back the least valued used cipher-suite, but the group including EKR, agreed to send back the complete via header. Thx Samir =20 >Ok. Is it possible to put Via's in the reverse direction? Or some other >way to inform >the originator of the forward/backward transport path's protection=20 >characteristics? >If so, wouldn't that do pretty much everything you want SIPS to do=20 >without the >unappealing all-or-nothing problems of SIPS? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 02:58:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXQV-0002fX-Qx; Thu, 02 Nov 2006 02:55:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXQT-0002ck-Uy for sip@ietf.org; Thu, 02 Nov 2006 02:55:49 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXQR-0007vk-Jc for sip@ietf.org; Thu, 02 Nov 2006 02:55:49 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA27tV325695; Thu, 2 Nov 2006 02:55:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 01:55:34 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875E4@zrc2hxm2.corp.nortel.com> In-Reply-To: <7C4DE77D-B70D-49C4-A6E2-29F40E754B76@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9/CLBLCO8x1QuT6ih+Yv1Tyj9AgAVgs5w From: "Samir Srivastava" To: "Dean Willis" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Do you want to say that your call to SIPS URI will be only secured. If I dial 411 etc, then we don't know. Can we convince our users with some calls are secured, others are not. With another wacky thread, I am still not getting convinced what we are achieving.. In your presence publications, and registration example .. My presence, registration can be leaked too, as there is No REQUIRE flag for not distributing my presence,reg info to watchers on the UNSECURE channel. Thx Samir > >So sip: gives us a best effort connection without a reporting=20 >mechanism. You want a best-effort connection with a new=20 >reporting mechanism. I think that's useful. I also didn't say=20 >it was a hard new mechanism to define, just that it's beyond=20 >the scope of a BCP to describe. > >The use case for sips: hasn't changed (except a recommendation=20 >for outbound-with-TLS instead of last-hop-excepting ) , and=20 >its obvious. =20 >One uses sips: only when one is absolutely insistent that each=20 >SIP hop be protected by TLS. This is very useful for MESSAGE=20 >requests, registrations, presence publications, subscription >notifications, and other usages where the SIP payload is the=20 >actual communication being protected. It enables key-exchange=20 >within SIP for resulting media sessions (although DH is still=20 >a better approach). And it helps to obscure the media=20 >descriptions, which doesn't protect the media channel directly=20 >but does complicate the task of an eavesdropper. > >There's clearly enough "use case" here for people to be deploying >sips: today. Just not enough specification for making those=20 >deployments as meaningful as they could be. > >-- >dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 03:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXUg-0007sI-5P; Thu, 02 Nov 2006 03:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXUe-0007s0-I3 for sip@ietf.org; Thu, 02 Nov 2006 03:00:08 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXUd-00005x-8X for sip@ietf.org; Thu, 02 Nov 2006 03:00:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 08:00:06 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23F6B@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down thread-index: Acb99XLqfdzBCmH2ShKlLdaYLfPdrQAX1N0g From: "Attila Sipos" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> > There is a benefit in having secure SIP being used upto >> > the PSTN gateway. >> > >>=20 >> Sure. And with the description of sip: URI processing given earlier =20 >> (it will be secured if it can be secured) then sip: gives=20 >> you as good =20 >> of security as you would get by lying about your compliance with =20 >> sips:. So placing a call using a sip: URI to the PSTN gateway would =20 >> produce secure SIP. In your orignal "A sips: trial balloon for you to shoot down" you said: >>1) Implementations of SIP SHOULD use TLS as described in RFC 3261 for = >>all SIP traffic, including traffic using a sip: URI scheme. Failure =20 >>to use TLS may result in disclosure of sensitive signaling =20 >>information to third parties. >>In other words, if you're willing to settle for the best =20 >>security that can actually be provided, simply originate the request =20 >>with a sip: URI scheme. So, what you're saying that PSTN gateways should use a sip: URI with transport=3Dtls? Can we, possibly with Requires, enforce that all hops use the TLS? Attila _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 03:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXzB-00052H-A1; Thu, 02 Nov 2006 03:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXz9-00051r-Kf for sip@ietf.org; Thu, 02 Nov 2006 03:31:39 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXz8-0004pj-8z for sip@ietf.org; Thu, 02 Nov 2006 03:31:39 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA28VW301291; Thu, 2 Nov 2006 03:31:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Thu, 2 Nov 2006 02:31:35 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875EA@zrc2hxm2.corp.nortel.com> In-Reply-To: <7E27C36F-2349-41EE-815E-A7E46010D812@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb+Bw3CT8cFFctZTtKqNDir3V1qXQAUGa8w From: "Samir Srivastava" To: "Dean Willis" , "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Great attempt to keep SIPS. Looks like you love complex solutions only... Thx Samir=20 >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: Wednesday, November 01, 2006 2:42 PM >To: Michael Thomas >Cc: Joel M. Halpern; IETF SIP List; Audet, Francois=20 >(SC100:3055); Elwell, John; Juha Heinanen >Subject: Re: What controls the lock icon? (Was RE: [Sip] RE:=20 >TLS meaning) > > >On Nov 1, 2006, at 3:51 PM, Michael Thomas wrote: > >> Dean Willis wrote: >> >>> >>> On Nov 1, 2006, at 3:40 PM, Michael Thomas wrote: >>> >>>> PS: is there any sort of notion of adding the transport=20 >protection =20 >>>> information in Via's >>>> like, oh say, sendmail does with Received headers with TLS? >>> >>> >>> yep, that's one way to get the "What happened downstream"=20 >info back =20 >>> so the nodes can operate under "informed consent". >> >> >> Ok. Is it possible to put Via's in the reverse direction? Or some=20 >> other way to inform the originator of the forward/backward=20 >transport=20 >> path's protection characteristics? >> > >History-Info, RFC 4244 is something like this. We're a little=20 >short on implementations so far, but I think it could be=20 >reasonably adapted to provide change-of-crypto "retargeting" info. > >> If so, wouldn't that do pretty much everything you want SIPS to do=20 >> without the unappealing all-or-nothing problems of SIPS? > >With the exception that you'd get an established dialog (or a=20 >MESSAGE request delivered) that has an unsecured connection in=20 >it, then say "oops". > >Here's a legit use case for sips: > >I want to send you a text message with moderately sensitive=20 >info. So I send it using your sips: request URI. If it turns=20 >out that a proxy out there can't honor that request for=20 >transitive protection, it rejects the request rather than=20 >exposing my sensitive text-bits to the harsh climes of an=20 >unencrypted channel. > >So I still need that "I want it" part of sips. With just a=20 >post-facto diagnostic (like History-Info) I'd have to first=20 >establish a dialog, then look and see if I liked the security,=20 >then send a MESSAGE over that dialog (considered to be abusing=20 >the dialog by the MESSAGE RFC), then tear the dialog down. > >But your proposal works great for the use case John and others=20 >have come up with -- "Ok, I've got a dialog. Now how am I=20 >going to use it?" > >-- >Dean > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 03:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfY4Z-0002jK-Qm; Thu, 02 Nov 2006 03:37:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfY4Y-0002j1-F1 for sip@ietf.org; Thu, 02 Nov 2006 03:37:14 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfY4T-0005qg-Lw for sip@ietf.org; Thu, 02 Nov 2006 03:37:14 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8300B5HH9XVA@siemenscomms.co.uk> for sip@ietf.org; Thu, 02 Nov 2006 08:37:09 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG66WY>; Thu, 02 Nov 2006 08:36:59 +0000 Content-return: allowed Date: Thu, 02 Nov 2006 08:36:58 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Dean Willis Message-id: <50B1CBA96870A34799A506B2313F26670A41085A@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Thanks. During all this long thread, this is the first time that anyone has been able to articulate a convincing use case. Messages with content, as opposed to situations where content is sent as media, do require different considerations. So when sending an INVITE request for an audio call, I might be content with best effort security because I can moderate what I say if security isn't available. But when sending a MESSAGE request I need to know in advance that it will be sent securely or not at all. Therefore I think I will stop trying to shoot down your trial balloon, apart from the point about PSTN, where I believe sips stops at the UAS, whatever that UAS is (a view that seems to be shared by a number of others). Dealing with whatever is beyond the UAS should be outside the scope of this BCP for sips. I do think we need to start considering where we go beyond this, including reporting on the security state to both UAs. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 01 November 2006 21:23 > To: Elwell, John > Cc: IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > On Nov 1, 2006, at 3:03 PM, Elwell, John wrote: > > > Dean, > > > > Not quite. See below. > > > > ... > > > [JRE] If we have a sips scheme that mandates TLS on all hops > > (whatever TLS > > might mean) and fails if it can't achieve it, I think there is an > > equal > > argument for a mechanism that requests TLS on all hops but still > > succeeds > > and tells me if any hop does not meet this requirement. So if we > > recommend > > the sip scheme for achieving best effort, it still doesn't tell me > > if it > > succeeded. Yes, what I want would be a new mechanism, but it would > > not be > > substantially more difficult to define than the SIPS mechanism. I > > am having > > a hard time rationalising why we should specify an all-or-nothing > > mechanism > > (sips) but not a best effort mechanism. In other words I am having > > a hard > > time understanding the use cases for sips. Maybe the lack of > > plausible use > > cases is part of the reason it hasn't been deployed much. > > > > So sip: gives us a best effort connection without a reporting > mechanism. You want a best-effort connection with a new reporting > mechanism. I think that's useful. I also didn't say it was a > hard new > mechanism to define, just that it's beyond the scope of a BCP to > describe. > > The use case for sips: hasn't changed (except a recommendation for > outbound-with-TLS instead of last-hop-excepting ) , and its obvious. > One uses sips: only when one is absolutely insistent that each SIP > hop be protected by TLS. This is very useful for MESSAGE requests, > registrations, presence publications, subscriptions, notifications, > and other usages where the SIP payload is the actual communication > being protected. It enables key-exchange within SIP for resulting > media sessions (although DH is still a better approach). And > it helps > to obscure the media descriptions, which doesn't protect the media > channel directly but does complicate the task of an eavesdropper. > > There's clearly enough "use case" here for people to be deploying > sips: today. Just not enough specification for making those > deployments as meaningful as they could be. > > -- > dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 04:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnu-0005vh-Ch; Thu, 02 Nov 2006 04:24:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnp-0005oh-LF for sip@ietf.org; Thu, 02 Nov 2006 04:24:01 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYbs-00049V-Ii for sip@ietf.org; Thu, 02 Nov 2006 04:11:43 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA29BYb8023305; Thu, 2 Nov 2006 11:11:35 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 11:11:35 +0200 Received: from [172.21.36.67] ([172.21.36.67]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Nov 2006 11:11:35 +0200 Message-ID: <4549B645.50907@nokia.com> Date: Thu, 02 Nov 2006 11:11:33 +0200 From: Aki Niemi Organization: Nokia-NRC/Helsinki User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <45490C2C.3060606@cisco.com> In-Reply-To: <45490C2C.3060606@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 09:11:35.0139 (UTC) FILETIME=[E5247330:01C6FE5E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061102111135-5652CBB0-68312F99/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "Joel M. Halpern" , 'IETF SIP List' , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rants are so much fun. Another inline. ext Jonathan Rosenberg kirjoitti: > rant inline. > > Dean Willis wrote: > > >> >> But please help us understand what's different about IPSEC usage in >> the IMS sense. >> >> IMS has a persistent IPSEC SA established between the edge proxy and >> the UA. Authentication is accomplished using the SIM as a token >> generator, and the crypto is one of the usual mechanisms (keep in >> mind TLS still allows plain small-key DES, which isn't all that >> strong). The applications are constructed so that the SIP function is >> aware of the SA and that it is connected to an authenticated party. > > Well, now you're going to get me started on how bad the IMS IPSec > mechanism is. > > > Its IPSEC, sure, but its keyed with a horrific > tunnel-keys-through-SIP-register mechanism. Given the immense > complication in designing secure keying protocols, I have a deep fear > that there is a lurking security hole in the way keying works in IMS. > Indeed, the specifications for this 'keying' protocol are about as > opaque as you can make them. They are deeply buried within IMS > specifications, bundled with lots of other stuff. This makes it nearly > impossible for broad analysis and critique from the security community, > which includes many folks (if not most) that would never be able to > penetrate the IMS specifications in order to comment. > > I'll also note that it is a massive layer violation; we're using an > application layer protocol to key a security protocol over which that > very same application layer protocol will run. Does that not simply > strike you as absurd? > > From an implementation perspective, the IMS security mechanism is a > nightmare. You can't use "standard" offloaders, since those assume > standardized keying mechanisms, not this insanity of using SIP for > keying. This makes IMS servers more expensive. You need to deeply > integrate your IPSec and SIP stacks. Awful!! > > If TCP is the stumbling block to using TLS in IMS, then DTLS to me would > be a blessing. Nothing would please me more than to deprecate the specs > that define this nightmare. Two in particular - the seemingly innocuous > RFC4169 which opens the door for sip-as-a-keying-protocol, and the even > more horrible RFC3329, which hides its real agenda of adding bid-down > prevention to SIP-the-IPSec-keying-protocol. Once deprecated, we can > tell 3gpp to use SIP over DTLS in R8. In all fairness, I don't remember you or anyone else offering DTLS as an alternative ~5 years ago when all this was specified. Nor did we have the PSK cipher suite for TLS, which IMO would go far in solving the IMS first-hop problem in a much, much cleaner way. Being involved in the work you mention, I would be first to admit it's an Utter Hack, and nothing would please me more than to see it go away. What's worse is that the way it's being implemented and deployed manages to lose the one bit that is actually worth something, i.e., the bid-down protection of sec-agree. I think we managed to lay in enough bugs in there, too, that interop is pretty horrible. But hey, live and learn. That said, the root of all evil here is UDP. It still escapes me why people insist on dragging that baggage around when all I see are cons with using UDP as transport. If anything, that's a massive layer violation to run SIP over UDP, and then replicate the state machine of TCP in SIP. A while ago there was speculation on the SIP WG list about defining delayed ACK for SIP to get around some weird error condition (pardon me, the details escape me ATM). That to me would have been the last spool that completes the reinvented wheel. People have cited performance problems for servers having to scale up with a huge number of TCP connections. I don't buy that. People have cited problems with mobile handsets not being able to handle TCP. Bogus. Even the low-end phones today handle TCP and run TLS just fine. If someone has a phone that doesn't, well, perhaps it's time to upgrade. What's nice about TCP is that the performance in presence of NAT tends to be a lot better than with UDP. In wide area cellular, using UDP keepalives will drain the battery unless you have the phone connected to a charger. And that pretty much defeats the purpose of a *mobile* device. So lets not forget what brought on the Rel5 security specs with their associated problems for the IMS. It was the total lack of a viable security solution for SIP over UDP, and the inability to use anything but Digest as the authentication method. Today, we're not much better off. Cheers, Aki P.S. I only guarantee the above to be well-formed, not necessarily valid. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 04:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZHF-0006lQ-TV; Thu, 02 Nov 2006 04:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZHE-0006lL-BI for sip@ietf.org; Thu, 02 Nov 2006 04:54:24 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZH9-0004HP-Kw for sip@ietf.org; Thu, 02 Nov 2006 04:54:24 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA29sEt21094; Thu, 2 Nov 2006 04:54:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: TLS meaning Date: Thu, 2 Nov 2006 03:54:16 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F6875F3@zrc2hxm2.corp.nortel.com> In-Reply-To: <454908DF.1020902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb99547OCwZk3MVTweUzgVZUB28tQAaJBMw From: "Samir Srivastava" To: "Jonathan Rosenberg" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, You have your right to vote and I respect your opinion. May I ask following question 1) How can I route the non-sip uri over the SIP network. When I need Proxy-Require for non SIP URI's then why not use the same Proxy-Require tag for SIP itself.=20 2) Without any additional flag for REQUIRE tag, my presence and reg-info is open to be sent on the unsecure channels to watchers. 3) IMHO, Proxies and routers cannot be compared. Routers only look into IPAddresses, where Proxies look into the complete SIP message to,from etc .. Knowing some IP Packets going between two IP address doesn't reveal much. But knowing To, From etc by any attacker on the wire does mean much. 4) SIPS doubles the entries in DNS, registrar etc.. (For SIPS, and SIP URIS.) Whereas Proxy-Require/Require doesn't require that. 5) How SIPS will interwork with more workable secure solutions ? With limited TLS (what it means still open) only, embedded with SIPS how do you want to upgrade it for DTLS.=20 6) If you believe in cipher-suite issue, then Proxy-Require for that makes SIPS redundant.=20 Thx Samir=20 >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: Wednesday, November 01, 2006 12:52 PM >To: Audet, Francois (SC100:3055) >Cc: IETF SIP List >Subject: Re: [Sip] RE: TLS meaning > >Well, many messages have come and gone since this one. So, I=20 >will respond to Francois's note here and make some additional points. > >My own opinion: > >1. no >2. yes > >I fear that much of the objection to sips is wound up in its=20 >name. Its not "secure SIP" in the sense that there are=20 >certainly attacks that remain even if you use it. However,=20 >there is really no such thing as "secure SIP", anymore than=20 >there is really such a thing as "secure HTTP". I'll point out=20 >that with attacks like phishing, even https isn't providing=20 >people with what they think is "secure web browsing". But let=20 >us not throw the baby out with the bathwater. > >What SIPS can do, once we fix it, is provide a particular=20 >property that I think is very valuable. In networks with=20 >trusted proxies, it prevents against a vast array of=20 >"outsider" attacks - eavesdropping, replay, modification, and=20 >so on. This property is very useful. I can't tell you how many=20 >SIP extensions have security considerations that are based on=20 >this property. > >Just because sips doesn't address insider attacks (where the=20 >proxies are not trusted), does not make it useless. To be=20 >frank I fear there will never be a deployable solution for=20 >security where you don't trust the proxies. Its kind of like=20 >hoping the Internet works when you don't trust the routers. It=20 >would be nice but it sounds hard. > >I believe we have also learned a lot since RFC 3261. WIth the=20 >arrival of sip-outbound, I believe we have the final tool=20 >needed to remove the last hop exception rule, and have a very=20 >useful security technique that is also extremely deployable.=20 >If you throw in DTLS as "ok" as well, you can even get around=20 >the TCP/UDP wars, and provide something that works for wireless too. > >My two cents, >Jonathan R. > >Francois Audet wrote: > >> In case people having noticed, it is looking like we are having a=20 >> mailing list hum on the following 2 questions: >>=20 >> 1 - Do you favour deprecating the sips scheme altogether (yes/no) >>=20 >> 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) >>=20 >>=20 >> Note: Voting Yes on 2 does not necessarily imply you are=20 >voting No on=20 >> 1, but it will only make sense if sips is not deprecated. >>=20 >> I'm keeping track of the vote. >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >>=20 > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 05:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZzc-0008NV-9H; Thu, 02 Nov 2006 05:40:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZza-0008LS-Ka for sip@ietf.org; Thu, 02 Nov 2006 05:40:14 -0500 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZzX-0004MV-2R for sip@ietf.org; Thu, 02 Nov 2006 05:40:14 -0500 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA2AdxRZ031619; Thu, 2 Nov 2006 11:39:59 +0100 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA2AdvsI007409; Thu, 2 Nov 2006 11:39:57 +0100 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 11:39:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Nov 2006 11:39:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification of the location-by-reference URI (location-conveyance-05) thread-index: Acb+azqexBXN51u/QUGstW95itIw5A== From: "Vrancken, Johnny" To: "James M. Polk" , "Brian Rosen" , X-OriginalArrivalTime: 02 Nov 2006 10:39:53.0579 (UTC) FILETIME=[3B423BB0:01C6FE6B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Subject: [Sip] Clarification of the location-by-reference URI (location-conveyance-05) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2104676397==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2104676397== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FE6B.3AD38AEE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FE6B.3AD38AEE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In =A73.2, it is stated that a location-by-reference URI is a pointer to = a record on a remote node containing location of the location target. The example in =A74.1 Geolocation: = does not contain a valid = sips-URI (definition provided in RFC 3261). A sip-URI / sips-URI / pres-URI typically has the user@domain format as = in the example of =A74.3. So a sip-URI / sips-URI / pres-URI typed location-by-reference URI = refers to the presentity/target to be subscribed to in order to obtain = the location information. If the location-by-reference URI is an absolute URI (not sip / sips / = pres ), then it may point directly to a record containing the location = of the target (e.g. https: //server5.atlanta.example.com/alice123) Question: does the UAS or the SIP intermediary has to include the = identity of the UAC when sending a SUBSCRIBE request to obtain the = location information? Some nits: + =A75.2 last sentence: ... is the same as the UAC as above. (not UAS) + =A73.2 contains contradictory statements for BYE (use of the = geolocation header not allowed / conveying location is not defined).=20 + application/pidf should be application/pidf+xml in Accept and = Content-Type headers + civilAddress should be civicAddress + mind the order of the XML elements in the examples ( the = beginning of , at the end of , child elements = of ) + =A74.1: urn of gml prefix is missing Kind regards, Johnny ------_=_NextPart_001_01C6FE6B.3AD38AEE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification of the location-by-reference URI = (location-conveyance-05)

Hi,

In =A73.2, it is = stated that a location-by-reference URI is a pointer to a record on a = remote node containing location of the location = target.

The example in = =A74.1 Geolocation: <sips:server5.atlanta.example.com/alice123> = does not contain a valid sips-URI (definition provided in RFC = 3261).

A sip-URI / = sips-URI / pres-URI typically has the user@domain format as in the = example of =A74.3.
So a = sip-URI  / sips-URI / pres-URI typed location-by-reference URI = refers to the presentity/target to be subscribed to in order to obtain = the location information.

If the = location-by-reference URI is an absolute URI (not sip / sips / pres ), = then it may point directly to a record containing the location of the = target

(e.g. https: = //server5.atlanta.example.com/alice123)

Question: does the = UAS or the SIP intermediary has to include the identity of the UAC when = sending a SUBSCRIBE request to obtain the location = information?

Some = nits:
+ =A75.2 last = sentence: … is the same as the UAC as above. (not = UAS)
+ =A73.2 contains = contradictory statements for BYE (use of the geolocation header not = allowed / conveying location is not defined).

+ application/pidf = should be application/pidf+xml in Accept and Content-Type = headers
+ civilAddress = should be civicAddress
+ mind the order = of the XML elements in the examples (<status> the beginning of = <tuple>, <timestamp> at the end of <tuple>, child = elements of <civicAddress>)

+ =A74.1: urn of = gml prefix is missing

Kind = regards,

Johnny

------_=_NextPart_001_01C6FE6B.3AD38AEE-- --===============2104676397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2104676397==-- From sip-bounces@ietf.org Thu Nov 02 08:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfc6S-0007T1-6k; Thu, 02 Nov 2006 07:55:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfc6P-0006vo-9h for sip@ietf.org; Thu, 02 Nov 2006 07:55:25 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfc1v-0004Cg-36 for sip@ietf.org; Thu, 02 Nov 2006 07:50:57 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kA2CokCk016133; Thu, 2 Nov 2006 06:50:46 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Nov 2006 06:50:45 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Nov 2006 13:50:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Date: Thu, 2 Nov 2006 13:50:32 +0100 Message-ID: <5D1A7985295922448D5550C94DE291806E0863@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Thread-Index: Acb+AWbytkvJq7YIQAmUdPX9bb7kXwAevGww From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 02 Nov 2006 12:50:44.0194 (UTC) FILETIME=[82970420:01C6FE7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the comments. Inline below:=20 Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 01 November 2006 22:02 > To: Drage, Keith (Keith) > Cc: SIP > Subject: Re: [Sip] Request for views on=20 > draft-drage-sip-essential-correction-00.txt >=20 > Keith, >=20 > I agree with the final step here, but I'm not so sure about=20 > your details of the intermediate steps. >=20 > In particular, I think it is too onerous to require one I-D=20 > per issue.=20 > FOr example it would be nice for someone to go through the=20 > bugzilla database and submit one I-D with all of the things=20 > in it that we need to put into the corrections spec. THis is=20 > more palatable than having to submit 30 separate documents,=20 > each 6 pages in length (5.5 pages overhead and 1/2 page for=20 > the useful content). I think flexibility is needed here. Grouping of related issues, are a number of well understood and non-controversial (but otherwise essential) corrections is probably OK. What we don't want to do is group things that require lots of discussion time in the WG (SIPS fixes?) with those that don't. Nor do we want to present two issues together such that one confuses the understanding and WG discussion of the other. >=20 > Also we need to discuss what happens when more bugs get=20 > reported after the correction RFC is published. DO we revise=20 > that RFC? Or issue another corrections document? >=20 The idea was that the reader only need read the original RFC plus 1 correction RFC. Thus as more corrections are discovered, we take the contents of the original correction RFC, the new fixes, and produce a new RFC that obsoletes the first correction RFC, but which still updates the original RFC. Remember however that the draft replacement correction RFC can still be rapidly put together - and it only needs IESG review and approval, as all the individual components have been WGLC separately. Therefore I see this process as being reasonably quick (in IETF terms). Note that in terms of the normal RFC process we would lose the correction RFC if we ever take any SIP documents from proposed standard to draft standard, i.e. the proposed standard RFC would obsolete the=20 > -Jonathan R. >=20 > Drage, Keith (Keith) wrote: >=20 > > I have recently submitted > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correcti > > on > > -00.txt > >=20 > > The idea behind this draft, is to put some management into getting=20 > > real > > bugfixes: > >=20 > > - into one place where people can find it > > - give it standards track RFC status so that people know they have > > to implement it. > >=20 > > If people not already consulted have views on this process, then=20 > > please let them be known. > >=20 > > The idea would be to start this process (taking into=20 > account any input=20 > > from the WG) after the next IETF meeting. > >=20 > > Regards > >=20 > > Keith > >=20 > > Keith Drage > > drage@lucent.com > > tel: +44 1793 776249 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 09:22:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdOu-0000VT-S8; Thu, 02 Nov 2006 09:18:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdOt-0000VI-4R for sip@ietf.org; Thu, 02 Nov 2006 09:18:35 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdOa-0000c9-TL for sip@ietf.org; Thu, 02 Nov 2006 09:18:35 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E88C1E91; Thu, 2 Nov 2006 15:17:37 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 15:17:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Nov 2006 15:17:35 +0100 Message-ID: <5D44628035C1F54BB415BBD135F5BECF5F4721@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: Indication of number of flows to register Thread-Index: Acb+iaSyX0DDYdb4T/yHYsrXuWtpEQ== From: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" , "Rohan Mahy" X-OriginalArrivalTime: 02 Nov 2006 14:17:37.0872 (UTC) FILETIME=[A62F2500:01C6FE89] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Sip] Outbound-05: Indication of number of flows to register X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0915067180==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0915067180== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FE89.A5C6684C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FE89.A5C6684C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One issue that has been discussed for outbound is to allow the network to indicate to the UA how many flows are accepted, and/or how many flows the user is recommended to register. This value could e.g. be provided by the registrar. Otherwise, if the maximum number of flows is reached, registration requests would have to be rejected, which is not good. So, my proposal is still that it should be added to outbound. Regards, Christer ------_=_NextPart_001_01C6FE89.A5C6684C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Outbound-05: Indication of number of flows to register

Hi,

One issue that has been discussed for = outbound is to allow the network to indicate to the UA how many flows = are accepted, and/or how many flows the user is recommended to register. = This value could e.g. be provided by the registrar. Otherwise, if the = maximum number of flows is reached, registration requests would have to = be rejected, which is not good.

So, my proposal is still that it should = be added to outbound.

Regards,

Christer

------_=_NextPart_001_01C6FE89.A5C6684C-- --===============0915067180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0915067180==-- From sip-bounces@ietf.org Thu Nov 02 11:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gff01-0004XR-HZ; Thu, 02 Nov 2006 11:01:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gff00-0004Uf-6v for sip@ietf.org; Thu, 02 Nov 2006 11:01:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfezw-0000Un-Oq for sip@ietf.org; Thu, 02 Nov 2006 11:01:00 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Nov 2006 08:00:56 -0800 X-IronPort-AV: i="4.09,381,1157353200"; d="scan'208"; a="753971931:sNHT57327308" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2G0usQ024622; Thu, 2 Nov 2006 08:00:56 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA2G0tW4002130; Thu, 2 Nov 2006 08:00:55 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn2-643.cisco.com [10.21.114.131]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA2FluZ9013788; Thu, 2 Nov 2006 07:47:59 -0800 Message-ID: <454A163A.9010302@cisco.com> Date: Thu, 02 Nov 2006 08:00:58 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> <45491452.50204@cisco.com> <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> <454916EE.5050105@cisco.com> <7E27C36F-2349-41EE-815E-A7E46010D812@softarmor.com> In-Reply-To: <7E27C36F-2349-41EE-815E-A7E46010D812@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4215; t=1162483256; x=1163347256; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3DGRW9K/sCSuDWaouFDQAw+1n+V/c=3D; b=S49IOirJWNzXdiMbL6R9V7PIUXZifA4YFdcHEc+OOglnFErLdduJIGi78/7ORNvRezyL+XDH 9JULGbFVRqrBThqTrQE2/KU2OoCTYXz6GOICE+ggEjTKS4ql4gFAeIzD; X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 1, 2006, at 3:51 PM, Michael Thomas wrote: > >> Dean Willis wrote: >> >>> >>> On Nov 1, 2006, at 3:40 PM, Michael Thomas wrote: >>> >>>> PS: is there any sort of notion of adding the transport >>>> protection information in Via's >>>> like, oh say, sendmail does with Received headers with TLS? >>> >>> >>> >>> yep, that's one way to get the "What happened downstream" info >>> back so the nodes can operate under "informed consent". >> >> >> >> Ok. Is it possible to put Via's in the reverse direction? Or some >> other way to inform >> the originator of the forward/backward transport path's protection >> characteristics? >> > > History-Info, RFC 4244 is something like this. We're a little short > on implementations so far, but I think it could be reasonably adapted > to provide change-of-crypto "retargeting" info. > >> If so, wouldn't that do pretty much everything you want SIPS to do >> without the >> unappealing all-or-nothing problems of SIPS? > > > With the exception that you'd get an established dialog (or a MESSAGE > request delivered) that has an unsecured connection in it, then say > "oops". Surely you could send some sort of NOP first? I guess that one of the my perhaps not hidden assumptions here is that you are amortizing the connection for more than one method being shoved down the piecewise pipe. > > Here's a legit use case for sips: > > I want to send you a text message with moderately sensitive info. So > I send it using your sips: request URI. If it turns out that a proxy > out there can't honor that request for transitive protection, it > rejects the request rather than exposing my sensitive text-bits to > the harsh climes of an unencrypted channel. > > So I still need that "I want it" part of sips. With just a post-facto > diagnostic (like History-Info) I'd have to first establish a dialog, > then look and see if I liked the security, then send a MESSAGE over > that dialog (considered to be abusing the dialog by the MESSAGE RFC), > then tear the dialog down. I guess this all gets down to whether stateless SIP is useful at all, which is a superset of the "is udp useful at all" argument. I'd say that establishing a bunch of TCP and/or TLS sessions is more "abusive" then just one extra e2e round trip after the dialog is established -- consider the zillions of round trips just to get things going on a fairly standard SIP trapezoid. If we *really* wanted statelessness, the messages ought to be self-contained, which while feasible for authentication is pretty problematic for confidentiality. So statelessness in combination with security seems unlikely to be sucessesful to me at least. So let's just not keep investing time on it? I've become pretty sympathetic to the idea of deprecating UDP over the years given these realities. Part of this for me is that SIP is just too damn complicated, and it's painfully obvious that it keeps getting itself wrapped around the axle because of some fairly high level decisions which at a high level seemed unrelated but have proven to be vexingly difficult to unify. It would be really nice to just chuck some of the decisions made mostly in a different time (cf Aki's note), and move on given the current reality. SIPS is one of these, UDP is probably another, and my sense is there are a whole host of things that I don't pay much attention to that qualify too. So I'll try to put this into a more constructive light rather than the whine above: why not make a BCP which discourages the use of things known to be problematic aiming at while not exactly deprecating, but end-of-life'ing those things so that we have a more manageable SIP going forward? Leave the problematic things alone for closed systems where they might be feasible, but stop developing for them for open internet standards where those assumptions can't be made. Mike > > But your proposal works great for the use case John and others have > come up with -- "Ok, I've got a dialog. Now how am I going to use 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 sip-bounces@ietf.org Thu Nov 02 13:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgqN-0002WH-Tj; Thu, 02 Nov 2006 12:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgqL-0002Sr-A4 for sip@ietf.org; Thu, 02 Nov 2006 12:59:09 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfgoq-0004N3-8a for sip@ietf.org; Thu, 02 Nov 2006 12:57:38 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA2H1AEu026946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 11:01:10 -0600 In-Reply-To: <454A163A.9010302@cisco.com> References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> <45491452.50204@cisco.com> <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> <454916EE.5050105@cisco.com> <7E27C36F-2349-41EE-815E-A7E46010D812@softarmor.com> <454A163A.9010302@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <853C067B-3637-4ACF-9471-7F720415C03A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Thu, 2 Nov 2006 11:57:31 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 2, 2006, at 10:00 AM, Michael Thomas wrote: > > Surely you could send some sort of NOP first? I guess that one of > the my perhaps > not hidden assumptions here is that you are amortizing the > connection for more > than one method being shoved down the piecewise pipe. > Sure you could. However, unless you bound the operation with a dialog (INVITE transaction, usually) there's no assurance that subsequent requests will follow the same path. So you might send a sip: NOP that would report "secure", then follow it with a sip: MESSAGE that would not be secured. >> >> Here's a legit use case for sips: >> >> I want to send you a text message with moderately sensitive info. >> So I send it using your sips: request URI. If it turns out that a >> proxy out there can't honor that request for transitive >> protection, it rejects the request rather than exposing my >> sensitive text-bits to the harsh climes of an unencrypted channel. >> >> So I still need that "I want it" part of sips. With just a post- >> facto diagnostic (like History-Info) I'd have to first establish >> a dialog, then look and see if I liked the security, then send a >> MESSAGE over that dialog (considered to be abusing the dialog by >> the MESSAGE RFC), then tear the dialog down. > > > I guess this all gets down to whether stateless SIP is useful at > all, which is a superset > of the "is udp useful at all" argument. I'd say that establishing a > bunch of TCP and/or > TLS sessions is more "abusive" then just one extra e2e round trip > after the dialog is > established -- consider the zillions of round trips just to get > things going on a fairly > standard SIP trapezoid. If we *really* wanted statelessness, the > messages ought to be > self-contained, which while feasible for authentFrom sip-bounces@ietf.org Thu Nov 02 13:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgqN-0002WH-Tj; Thu, 02 Nov 2006 12:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgqL-0002Sr-A4 for sip@ietf.org; Thu, 02 Nov 2006 12:59:09 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfgoq-0004N3-8a for sip@ietf.org; Thu, 02 Nov 2006 12:57:38 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA2H1AEu026946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 11:01:10 -0600 In-Reply-To: <454A163A.9010302@cisco.com> References: <50B1CBA96870A34799A506B2313F26670A4107DE@ntht201e.siemenscomms.co.uk> <45491452.50204@cisco.com> <6FD192F4-7DC9-42F5-9B42-DC0896360506@softarmor.com> <454916EE.5050105@cisco.com> <7E27C36F-2349-41EE-815E-A7E46010D812@softarmor.com> <454A163A.9010302@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <853C067B-3637-4ACF-9471-7F720415C03A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Thu, 2 Nov 2006 11:57:31 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , "Elwell, John" , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 2, 2006, at 10:00 AM, Michael Thomas wrote: > > Surely you could send some sort of NOP first? I guess that one of > the my perhaps > not hidden assumptions here is that you are amortizing the > connection for more > than one method being shoved down the piecewise pipe. > Sure you could. However, unless you bound the operation with a dialog (INVITE transaction, usually) there's no assurance that subsequent requests will follow the same path. So you might send a sip: NOP that would report "secure", then follow it with a sip: MESSAGE that would not be secured. >> >> Here's a legit use case for sips: >> >> I want to send you a text message with moderately sensitive info. >> So I send it using your sips: request URI. If it turns out that a >> proxy out there can't honor that request for transitive >> protection, it rejects the request rather than exposing my >> sensitive text-bits to the harsh climes of an unencrypted channel. >> >> So I still need that "I want it" part of sips. With just a post- >> facto diagnostic (like History-Info) I'd have to first establish >> a dialog, then look and see if I liked the security, then send a >> MESSAGE over that dialog (considered to be abusing the dialog by >> the MESSAGE RFC), then tear the dialog down. > > > I guess this all gets down to whether stateless SIP is useful at > all, which is a superset > of the "is udp useful at all" argument. I'd say that establishing a > bunch of TCP and/or > TLS sessions is more "abusive" then just one extra e2e round trip > after the dialog is > established -- consider the zillions of round trips just to get > things going on a fairly > standard SIP trapezoid. If we *really* wanted statelessness, the > messages ought to be > self-contained, which while feasible for authentication is pretty > problematic for > confidentiality. So statelessness in combination with security > seems unlikely to be > sucessesful to me at least. So let's just not keep investing time > on it? I've become > pretty sympathetic to the idea of deprecating UDP over the years > given these > realities. I don't disagree, but that sort of change requires normative change to standards-track RFCs, not usage guidlines. > > Part of this for me is that SIP is just too damn complicated, and > it's painfully > obvious that it keeps getting itself wrapped around the axle > because of some > fairly high level decisions which at a high level seemed unrelated > but have > proven to be vexingly difficult to unify. It would be really nice > to just chuck > some of the decisions made mostly in a different time (cf Aki's > note), and > move on given the current reality. SIPS is one of these, UDP is > probably > another, and my sense is there are a whole host of things that I > don't pay > much attention to that qualify too. > Choir preaching! > So I'll try to put this into a more constructive light rather than > the whine above: > why not make a BCP which discourages the use of things known to be > problematic > aiming at while not exactly deprecating, but end-of-life'ing those > things so that > we have a more manageable SIP going forward? Leave the problematic > things > alone for closed systems where they might be feasible, but stop > developing for > them for open internet standards where those assumptions can't be > made. Might be reasonable. There are limits, of course, to what one can change in a BCP. For example, one can say "The RFCs allow options A and B. A has been proven not to work, so we suggest you use B". One can't add a new option with a BCP. And unfortunately, we may need a new option in order not to run afoul of the current RFC-tangle. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 13:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfgqb-0002kd-Pt; Thu, 02 Nov 2006 12:59:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgqV-0002WV-9X for sip@ietf.org; Thu, 02 Nov 2006 12:59:19 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfgj7-0003u1-DY for sip@ietf.org; Thu, 02 Nov 2006 12:51:42 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA2GtF5D026912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 10:55:16 -0600 In-Reply-To: <4549B645.50907@nokia.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82865BE3-7273-42E6-AD33-EA4D17A13B9F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Thu, 2 Nov 2006 11:51:37 -0600 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Joel M. Halpern" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Pication is pretty > problematic for > confidentiality. So statelessness in combination with security > seems unlikely to be > sucessesful to me at least. So let's just not keep investing time > on it? I've become > pretty sympathetic to the idea of deprecating UDP over the years > given these > realities. I don't disagree, but that sort of change requires normative change to standards-track RFCs, not usage guidlines. > > Part of this for me is that SIP is just too damn complicated, and > it's painfully > obvious that it keeps getting itself wrapped around the axle > because of some > fairly high level decisions which at a high level seemed unrelated > but have > proven to be vexingly difficult to unify. It would be really nice > to just chuck > some of the decisions made mostly in a different time (cf Aki's > note), and > move on given the current reality. SIPS is one of these, UDP is > probably > another, and my sense is there are a whole host of things that I > don't pay > much attention to that qualify too. > Choir preaching! > So I'll try to put this into a more constructive light rather than > the whine above: > why not make a BCP which discourages the use of things known to be > problematic > aiming at while not exactly deprecating, but end-of-life'ing those > things so that > we have a more manageable SIP going forward? Leave the problematic > things > alone for closed systems where they might be feasible, but stop > developing for > them for open internet standards where those assumptions can't be > made. Might be reasonable. There are limits, of course, to what one can change in a BCP. For example, one can say "The RFCs allow options A and B. A has been proven not to work, so we suggest you use B". One can't add a new option with a BCP. And unfortunately, we may need a new option in order not to run afoul of the current RFC-tangle. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 13:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfgqb-0002kd-Pt; Thu, 02 Nov 2006 12:59:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgqV-0002WV-9X for sip@ietf.org; Thu, 02 Nov 2006 12:59:19 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfgj7-0003u1-DY for sip@ietf.org; Thu, 02 Nov 2006 12:51:42 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA2GtF5D026912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 10:55:16 -0600 In-Reply-To: <4549B645.50907@nokia.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82865BE3-7273-42E6-AD33-EA4D17A13B9F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Thu, 2 Nov 2006 11:51:37 -0600 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Joel M. Halpern" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 2, 2006, at 3:11 AM, Aki Niemi wrote: > Rants are so much fun. Another inline. Excellent rant, which could be summarized as "deprecate UDP". I think that's an interesting suggestion. It almost sounds like something I might have said myself at some timeIt would also solve our large- responses problem, and our "oh my god my request is too big to send in one packet" problem, and a bazillion other things. It does have a bit of susceptibility to the RST DOS attack of TCP to think about, something that DTLS does not suffer from. But other than that and inertia I can think of no good reason to keep using UDP. I'll note however that Robert reports that SIPit seems to indicate that most implementations are dealing with fragmented UDP just fine and nobody is actually noticing any problems with large packets, so we may be "burning a straw witch" when we worry about fragmentation. Personally, I'm far more worried about rampant complexity. -- 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 recedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 2, 2006, at 3:11 AM, Aki Niemi wrote: > Rants are so much fun. Another inline. Excellent rant, which could be summarized as "deprecate UDP". I think that's an interesting suggestion. It almost sounds like something I might have said myself at some timeIt would also solve our large- responses problem, and our "oh my god my request is too big to send in one packet" problem, and a bazillion other things. It does have a bit of susceptibility to the RST DOS attack of TCP to think about, something that DTLS does not suffer from. But other than that and inertia I can think of no good reason to keep using UDP. I'll note however that Robert reports that SIPit seems to indicate that most implementations are dealing with fragmented UDP just fine and nobody is actually noticing any problems with large packets, so we may be "burning a straw witch" when we worry about fragmentation. Personally, I'm far more worried about rampant complexity. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 13:03:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfgsb-0003Z8-9J; Thu, 02 Nov 2006 13:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfgqo-0002q6-5V for sip@ietf.org; Thu, 02 Nov 2006 12:59:38 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfgbh-0003Ii-MX for sip@ietf.org; Thu, 02 Nov 2006 12:44:06 -0500 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA2GlbXG026878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 10:47:38 -0600 In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0C23F6B@veg-brk-svr-pri.vegastream> References: <8F1F2062CA7D754A838F0E66097D23A0C23F6B@veg-brk-svr-pri.vegastream> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <294C98BE-76AA-4BB0-82E3-11C0B6D713E1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 11:43:58 -0600 To: "Attila Sipos" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Attila aksed: > So, what you're saying that PSTN gateways should use a > sip: URI with transport=tls? > I think so. > Can we, possibly with Requires, enforce that all hops > use the TLS? We possibly could, but that would be a new SIP extension, not part of the current sips: specification, and outside of the scope of what could be done with an informational or BCP document. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 14:24:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfi6S-0001MZ-27; Thu, 02 Nov 2006 14:19:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfi6Q-0001M1-Aj for sip@ietf.org; Thu, 02 Nov 2006 14:19:50 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfi6L-0007b3-Ow for sip@ietf.org; Thu, 02 Nov 2006 14:19:50 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA2JJgF29306; Thu, 2 Nov 2006 14:19:42 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6FEB3.D0F6295E" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 13:19:27 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DD3D57D@zrc2hxm0.corp.nortel.com> In-Reply-To: <294C98BE-76AA-4BB0-82E3-11C0B6D713E1@softarmor.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb+qalAXgx7r2RWReWRdzyK00E7KAACBm5Q From: "Francois Audet" To: "Dean Willis" , "Attila Sipos" X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FEB3.D0F6295E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, November 02, 2006 9:44 AM > To: Attila Sipos > Cc: IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 > Attila aksed: > > So, what you're saying that PSTN gateways should use a > > sip: URI with transport=3Dtls? > > >=20 > I think so. That would require a normative change to RFC 3261 which has=20 deprecated transport=3Dtls. Furthermore, I think this is a bad idea to be honest. I'd rather have the suggestion that someone made that requests with SIPoverTLS be forwarded to SIPoverTLS by proxies. I think we have 4 choices for PSTN Gateways: 1 - SIPS is only valid if all hops are withing a SIP network. PSTN gateways would therefore not use SIPS. Gateways to H.323 wouldn't either, even if H.323 is secured (same thing for other protocols). 2 - SIPS is valid withing an IP network. H.323 gateways could=20 use SIPS, provided they are using an equivalent security level on the H.323 side. PSTN gateways gateways would therefore not use SIPS. 3 - SIPS is significant only withing a SIP network, and hop-off to PSTN or other networks such as H.323 ARE allowed (in the case of H.323, it would require security).=20 4 - SIPS is significant only withing a SIP network, and hop-off to PSTN or other networks such as H.323 ARE allowed and in both cases, you would require the gateway network to use security.=20 I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. There are quite different however.=20 1 is my farorite choice if we think that sips has a limitted life-span and will have limited deployment, and will eventually be replaced by something better. 2 is my favorite if we believe sips has a more long-term future. > > Can we, possibly with Requires, enforce that all hops use the TLS? >=20 > We possibly could, but that would be a new SIP extension, not=20 > part of the current sips: specification, and outside of the=20 > scope of what could be done with an informational or BCP document. Right. ------_=_NextPart_001_01C6FEB3.D0F6295E Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: from zcarhxm2.corp.nortel.com ([47.129.230.99]) by zrc2hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 09:33:48 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C6FE94.4A315600" Content-class: urn:content-classes:message Return-Path: x-mimeole: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 02 Nov 2006 15:33:48.0197 (UTC) FILETIME=[4A4F6550:01C6FE94] Subject: RE: Updated: Harpooon IPT Core Team Meeting Date: Thu, 2 Nov 2006 09:33:45 -0600 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE0C24DCE2@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Updated: Harpooon IPT Core Team Meeting Thread-Index: AcZX60+/LbjtXd92T8qC5nTzLO3ADBBeAjYAAAEaFDAZSwEzkA== From: "Bermel, Karl \(CAR:9P40\)" To: "LeBlanc, Vicki \(CAR:4802\)" , "Brookes, Russ \(BVW:9X62\)" , "Knowles, Gregory \(NCRTP:4470\)" , "Taylor, Christopher \(CAR:9P91\)" , "Alvarez, Carlos \(NGD:8544\)" , "Potts, Brian \(BRAM:9731\)" , "Howard, Dave \(BVW:9X62\)" , "Jones, Kenneth \(NCRTP:4470\)" , "Knight, Diane \(BL60:9115\)" , "LaViolette, Denise \(BVW:4802\)" , "Shepherd, Frank \(SAMH:3065\)" , "Bree, Paul \(GAL:514\)" , "Reid, Diane INNOV \(External:EXTRNL:INNOV\)" , "Marshall, Bill \(BVW:9P05\)" , "Deacon, Donald \(BVW:6403\)" , "Opel, Harjit \(TORWM:1626\)" , "Douet, Philippe \(NGD:6403\)" , "James, Jud \(RICH7:7011\)" , "Keene-Moore, Jennifer \(RICH1:N126\)" , "Audet, Francois \(SC100:3055\)" , "Rouette, John \(WIC:1025\)" , "Van Vlack, Obadiah \(BVW:9P40\)" , "Lowe, Sara \(NGD:PJ01\)" , "Morrison, David [SC100:4308:EXCH]" , "Tworek, Richard \(BVW:9P00\)" , "Pierson, Alex \(CAR:9P00\)" , "Cleary, Colm \(GAL:6140\)" , "Davis, Todd \(RICH1:3058\)" , "Dearaujo, Daniel \(BVW:9P52\)" , "Drown, Scott \(BL60:3058\)" , "Gervais, Dean \(CAR:4802\)" , "Harris, Dean \(WWP1:6403\)" , "Hobbs, Neal \(MOP:4721\)" , "Kivell, Tom \(BL60:4470\)" , "LaRose, Ron \(BRAM:9P73\)" , "Maclaren, Ian \(CAR:9P10\)" , "Mckenna, Christine \(BVW:9P05\)" , "Pallen, Stephen \(BVW:9T13\)" , "Reissner, Peter \(BVW:9T16\)" , "Searles, Todd \(BVW:4802\)" , "Trailin, Alexander \(WIC:9T19\)" , "Tsui, Stephen \(SUNP:R710\)" This is a multi-part message in MIME format. ------_=_NextPart_002_01C6FE94.4A315600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks Notwithstanding the minor NCR (that will be corrected) we did very well = - as expected - on the ISO audit this week. Good job to everyone on the = team, and thanks to everyone involved, especially Vicki who has been = keeping us honest wrt TTM process and quality. Karl Bermel=20 (613) 763-9305 (ESN 393) kbermel@nortelnetworks.com =20 <>=20 ------_=_NextPart_002_01C6FE94.4A315600 Content-Type: text/html; name="RE How did MCS 5100 Release 4.0 finish.htm" Content-Transfer-Encoding: base64 Content-Description: RE How did MCS 5100 Release 4.0 finish.htm Content-Disposition: attachment; filename="RE How did MCS 5100 Release 4.0 finish.htm" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+DQo8 TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE1NjEiIG5hbWU9R0VORVJBVE9SPg0KPFNU WUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBTaW1TdW47DQp9DQpAZm9udC1mYWNlIHsN Cglmb250LWZhbWlseTogQFNpbVN1bjsNCn0NCkBwYWdlIFNlY3Rpb24xIHtzaXplOiA4LjVpbiAx MS4waW47IG1hcmdpbjogMS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjsgfQ0KUC5Nc29Ob3JtYWwg ew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJU aW1lcyBOZXcgUm9tYW4iDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFS R0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYu TXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQt RkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjog Ymx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6 ICM2MDY0MjA7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlu a0ZvbGxvd2VkIHsNCglDT0xPUjogIzYwNjQyMDsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUN Cn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglGT05ULVdFSUdIVDogbm9ybWFsOyBDT0xPUjogd2lu ZG93dGV4dDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULUZBTUlMWTogQXJpYWw7IFRFWFQtREVD T1JBVElPTjogbm9uZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0KPC9T VFlMRT4NCjwvSEVBRD4NCjxCT0RZIGxhbmc9RU4tVVMgdkxpbms9IzYwNjQyMCBsaW5rPWJsdWU+ PEI+RnJvbTo8L0I+IEhpbGwsIFJpY2hhcmQgDQooQlZXOjQ4MDIpPEJSPjxCPlNlbnQ6PC9CPiBU aHVyc2RheSwgTm92ZW1iZXIgMDIsIDIwMDYgMTA6MjYgQU08QlI+PEI+VG86PC9CPiANCkxlQmxh bmMsIFZpY2tpIChDQVI6NDgwMik8QlI+PEI+Q2M6PC9CPiBCZXJtZWwsIEthcmwgKENBUjo5UDQw KTsgSGF0Y2hlciwgR3JleSANCihOQVNIRjo2NDAzKTsgU2FyZ2VudCwgRGF2ZSAoQlZXOjlUNjAp OyBTYW1hcmFzZWtlcmEsIFNhbWFudGhpIChCVlc6OVA3Myk7IA0KR2VuZXJlYXV4LCBTdGVwaGVu IChCVlc6OVA3Mik8QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBIb3cgZGlkIE1DUyA1MTAwLCBSZWxl YXNlIA0KNC4wIGZpbmlzaD88QlI+DQo8RElWPjxTUEFOIGNsYXNzPTIzMjU0NDQxMy0wMjExMjAw Nj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jMDAwMDgwIA0Kc2l6ZT0yPkhpLCBW aWNraSw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1T IiBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTIzMjU0NDQxMy0wMjExMjAwNj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0j MDAwMDgwIA0Kc2l6ZT0yPk92ZXJhbGwsIEkgdGhpbmsgUGV0ZXIgVm9sZG5lciB3YXMgaW1wcmVz c2VkIHdpdGggNC4wLCBiYXNlZCBvbiBoaXMgDQppbnRlcnZpZXdzIHdpdGggS2FybCBhbmQgeW91 cnNlbGYsIERhdmUsIGFuZCBEbWl0cnkgS2xldmFraW4gKCEpLiZuYnNwOyBIZSANCmxpa2VkOjwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8VUw+DQogIDxMST48U1BBTiBjbGFzcz0yMzI1NDQ0MTMtMDIx MTIwMDY+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAwMDA4MCANCiAgc2l6ZT0y PnRoZSBRdWFsaXR5IFBsYW4sIHBhcnRpY3VsYXJseSB0aGUgb2JqZWN0aXZlcyBhcm91bmQgQ1Jz IChiYWNrbG9nIA0KICByZWR1Y3Rpb24gYW5kIG5ldyAmYW1wOyBjaGFuZ2VkIHRhcmdldHMpIGFu ZCB0aGUgdHJhY2tpbmcgdG8gdGhvc2UgDQogIG9iamVjdGl2ZXM8L0ZPTlQ+PC9TUEFOPiANCiAg PExJPjxTUEFOIGNsYXNzPTIzMjU0NDQxMy0wMjExMjAwNj48Rk9OVCBmYWNlPSJDb21pYyBTYW5z IE1TIiBjb2xvcj0jMDAwMDgwIA0KICBzaXplPTI+dGhlIGFjdGlvbiBhbmQgcmlzayBjYXB0dXJl IGFuZCB0cmFja2luZzwvRk9OVD48L1NQQU4+IA0KICA8TEk+PFNQQU4gY2xhc3M9MjMyNTQ0NDEz LTAyMTEyMDA2PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwODAgDQogIHNp emU9Mj50aGUgdXNlIG9mIGxlc3NvbnMgbGVhcm5lZCBmcm9tIDMuNSBpbiB0aGUgcGxhbm5pbmcg b2YgDQogIDQuMDwvRk9OVD48L1NQQU4+IA0KICA8TEk+PFNQQU4gY2xhc3M9MjMyNTQ0NDEzLTAy MTEyMDA2PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwODAgDQogIHNpemU9 Mj50aGUgZGVjaXNpb24gdG8gc3RyaWN0bHkgbGltaXQgY2h1cm4gKG9uZSBvZiB0aGUgMy41IGxl c3NvbnMgDQogIGxlYXJuZWQpPC9GT05UPjwvU1BBTj48L0xJPjwvVUw+DQo8RElWPjxTUEFOIGNs YXNzPTIzMjU0NDQxMy0wMjExMjAwNj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0j MDAwMDgwIA0Kc2l6ZT0yPkEgZmV3IG1pbm9yIHRoaW5ncyB3ZXJlIGNvbW1lbnRlZCBvbjo8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KPFVMPg0KICA8TEk+PFNQQU4gY2xhc3M9MjMyNTQ0NDEzLTAyMTEy MDA2PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwODAgDQogIHNpemU9Mj5U aGUgcmV2aWV3IHJlY29yZHMgZm9yIHRoZSBGRCAoSSB0aGluayAtIHRoZXJlIHdhc24ndCBhbiBG UywgcmlnaHQ/KSANCiAgZGlkbid0IGNsZWFybHkgaW5kaWNhdGUgd2hhdCB2ZXJzaW9uIG9mIHRo ZSBkb2N1bWVudCB3YXMgcmV2aWV3ZWQsIA0KICBub3ImbmJzcDtob3cgdGhlIHZhcmlvdXMgYWN0 aW9ucyB3ZXJlIHJlc29sdmVkLjwvRk9OVD48L1NQQU4+IA0KICA8TEk+PFNQQU4gY2xhc3M9MjMy NTQ0NDEzLTAyMTEyMDA2PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwODAg DQogIHNpemU9Mj5JdCB3b3VsZCBiZSBkZXNpcmFibGUgdG8gYmUgYWJsZSB0byBxdWFudGlmeSB0 aGUgcG9zaXRpdmUgaW1wYWN0IG9mIHRoZSANCiAgcHJvY2VzcyBpbXByb3ZlbWVudHMgbWFkZSBp biA0LjAgYmFzZWQgb24gdGhlIDMuNSBsZXNzb25zIA0KICBsZWFybmVkLjwvRk9OVD48L1NQQU4+ IA0KICA8TEk+PFNQQU4gY2xhc3M9MjMyNTQ0NDEzLTAyMTEyMDA2PjxGT05UIGZhY2U9IkNvbWlj IFNhbnMgTVMiIGNvbG9yPSMwMDAwODAgDQogIHNpemU9Mj5UaGUgY3VycmVudCB2ZXJzaW9uIG9m IHRoZSBGRCBpcyB2LiAyLjIsIGJ1dCBpdHMgcmV2aXNpb24gaGlzdG9yeSBpcyANCiAgbWlzc2lu ZyBhIDIuMiBsaW5lLiZuYnNwOyBUaGlzLCB0b2dldGhlciB3aXRoIHJldmlzaW9uIGhpc3Rvcnkg cmVsYXRlZCBpc3N1ZXMgDQogIHNlZW4gb24gYSBjb3VwbGUgb2Ygb3RoZXIgZG9jdW1lbnRzIG9u IG90aGVyIHByb2plY3RzLCBsZWQgdG8gdGhlIHJhaXNpbmcgb2YgYSANCiAgbWlub3IgTkNSIHJl OiBkb2N1bWVudCByZXZpc2lvbiBoaXN0b3JpZXMuJm5ic3A7IDxVPlRoZSBGRCAyLjIgcmV2aXNp b24gDQogIGhpc3RvcnkgbmVlZHMgdG8gYmUgY29ycmVjdGVkLiZuYnNwOyBQbGVhc2UgbGV0IG1l IGtub3cgd2hlbiBpdCBoYXMgYmVlbiANCiAgZG9uZS48L1U+PC9GT05UPjwvU1BBTj48L0xJPjwv VUw+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3J0ZiBmb3JtYXQgLS0+DQo8UD48Rk9OVCBmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jMDAwMDgwIHNpemU9Mj5JZiB5b3UgaGF2ZSBhbnkgcXVl c3Rpb25zLCANCnBsZWFzZSBnaXZlIG1lIGEgY2FsbC48L0ZPTlQ+IDwvUD4NCjxQPjxGT05UIGZh Y2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwODAgc2l6ZT0yPlRoYW5rczxTUEFOIA0KY2xh c3M9MjMyNTQ0NDEzLTAyMTEyMDA2PiBmb3IgYmVpbmcgcHJvYWN0aXZlIGFib3V0IHByZXBwaW5n IGZvciB0aGUgYXVkaXQsIGFuZCANCmZvciB0aGUgd2F5IHlvdSBoYW5kbGVkIHRoZSBpbnRlcnZp ZXdzLiZuYnNwOyBHb29kIGpvYiE8L1NQQU4+PC9GT05UPiA8L1A+DQo8UD48Qj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPlIuPC9GT05UPjwvQj4gPC9QPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciBz dHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWPjwvRElWPg0KICA8RElWIGNsYXNzPU91 dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIA0K ICBmYWNlPVRhaG9tYSBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJv bTo8L0I+IExlQmxhbmMsIFZpY2tpIA0KICAoQ0FSOjQ4MDIpIDxCUj48Qj5TZW50OjwvQj4gV2Vk bmVzZGF5LCBOb3ZlbWJlciAwMSwgMjAwNiA5OjI3IEFNPEJSPjxCPlRvOjwvQj4gDQogIEhpbGws IFJpY2hhcmQgKEJWVzo0ODAyKTxCUj48Qj5DYzo8L0I+IEJlcm1lbCwgS2FybCAoQ0FSOjlQNDAp OyBIYXRjaGVyLCBHcmV5IA0KICAoTkFTSEY6NjQwMyk7IFNhcmdlbnQsIERhdmUgKEJWVzo5VDYw KTsgU2FtYXJhc2VrZXJhLCBTYW1hbnRoaSAoQlZXOjlQNzMpOyANCiAgR2VuZXJlYXV4LCBTdGVw aGVuIChCVlc6OVA3Mik8QlI+PEI+U3ViamVjdDo8L0I+IEhvdyBkaWQgTUNTIDUxMDAsIFJlbGVh c2UgNC4wIA0KICBmaW5pc2g/PEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxESVYgY2xhc3M9U2Vj dGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BB TiBsYW5nPUVOLUNBIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJp YWwiPkhleSBSaWNrLDwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gbGFuZz1FTi1DQSANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGxhbmc9RU4t Q0EgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+V2hlbiBj YW4gd2UgaGVhciBhYm91dCB0aGUgTUNTIA0KICA1MTAwLCBSZWxlYXNlIDQuMCBhdWRpdCByZXN1 bHRzPzwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gbGFuZz1FTi1DQSANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIGxhbmc9 RU4tQ0EgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxJTUcgaGVpZ2h0PTQ4IHNyYz0iY2lk OjIzMjU0NDQxM0AwMjExMjAwNi0yQzA2IiANCiAgd2lkdGg9NzY+PC9TUEFOPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9Mz48U1BBTiBsYW5nPUZSIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0la RTogMTJwdCI+Vmlja2kgDQogIExlQmxhbmM8L1NQQU4+PC9GT05UPjwvQj48U1BBTiBsYW5nPUZS Piw8L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPTI+PFNQQU4gbGFuZz1GUiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+ UHJvZ3JhbSBNYW5hZ2VtZW50LCBFU0NTICZhbXA7IE1BIA0KICBUZWFtLDwvU1BBTj48L0ZPTlQ+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPTI+PFNQQU4gbGFuZz1FTi1DQSANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Tm9ydGVs LjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQQU4gbGFuZz1FTi1DQSANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+UGhvbmU6IDYxMy03NjMtNTA5OCAoRVNOIDM5Myk8L1NQQU4+PC9GT05UPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tQ0EgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPkVtYWlsOiBsZWJs YW5jdkBub3J0ZWwuY29tPC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiBsYW5nPUVOLUNBIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48L0RJVj48L0JM T0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_002_01C6FE94.4A315600-- ------_=_NextPart_001_01C6FEB3.D0F6295E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C6FEB3.D0F6295E-- From sip-bounces@ietf.org Thu Nov 02 15:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfixE-00074r-Pu; Thu, 02 Nov 2006 15:14:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfixD-00072n-Ko for sip@ietf.org; Thu, 02 Nov 2006 15:14:23 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfix8-0007bE-9E for sip@ietf.org; Thu, 02 Nov 2006 15:14:23 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gfiws-0006cv-W9; Thu, 02 Nov 2006 14:14:03 -0600 From: "Brian Rosen" To: "'Francois Audet'" , "'Dean Willis'" , "'Attila Sipos'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 15:14:05 -0500 Message-ID: <02ff01c6febb$74d4a430$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb+qalAXgx7r2RWReWRdzyK00E7KAACBm5QAAJUGHA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DD3D57D@zrc2hxm0.corp.nortel.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I favor 2, I can live with 1. "only valid" means fail if you can't maintain it. So, a gateway to H.323 acting as a UAS would fail a sips INVITE if 1 was the policy, and allow it if 2 was the policy AND it could maintain TLS throughout the H.323 signaling path. I'm not in favor of 3 or 4. Brian > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, November 02, 2006 2:19 PM > To: Dean Willis; Attila Sipos > Cc: IETF SIP List > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, November 02, 2006 9:44 AM > > To: Attila Sipos > > Cc: IETF SIP List > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > > > > Attila aksed: > > > So, what you're saying that PSTN gateways should use a > > > sip: URI with transport=tls? > > > > > > > I think so. > > That would require a normative change to RFC 3261 which has > deprecated transport=tls. > > Furthermore, I think this is a bad idea to be honest. I'd rather > have the suggestion that someone made that requests with SIPoverTLS > be forwarded to SIPoverTLS by proxies. > > I think we have 4 choices for PSTN Gateways: > > 1 - SIPS is only valid if all hops are withing a SIP network. PSTN > gateways would therefore not use SIPS. Gateways to H.323 wouldn't > either, even if H.323 is secured (same thing for other protocols). > > 2 - SIPS is valid withing an IP network. H.323 gateways could > use SIPS, provided they are using an equivalent security level on > the H.323 side. PSTN gateways gateways would therefore not use SIPS. > > 3 - SIPS is significant only withing a SIP network, and hop-off to PSTN > or other networks such as H.323 ARE allowed (in the case of H.323, > it would > require security). > > 4 - SIPS is significant only withing a SIP network, and hop-off to PSTN > or other networks such as H.323 ARE allowed and in both cases, you > would require the gateway network to use security. > > I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. > > There are quite different however. > > 1 is my farorite choice if we think that sips has a limitted life-span > and > will have limited deployment, and will eventually be replaced by > something better. > > 2 is my favorite if we believe sips has a more long-term future. > > > > Can we, possibly with Requires, enforce that all hops use the TLS? > > > > We possibly could, but that would be a new SIP extension, not > > part of the current sips: specification, and outside of the > > scope of what could be done with an informational or BCP document. > > Right. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 16:01:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfjdH-0001EE-Sh; Thu, 02 Nov 2006 15:57:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfjdG-0001E6-9x for sip@ietf.org; Thu, 02 Nov 2006 15:57:50 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfjdB-0004CJ-Sx for sip@ietf.org; Thu, 02 Nov 2006 15:57:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 20:57:44 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3632@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down thread-index: Acb+qalAXgx7r2RWReWRdzyK00E7KAACBm5QAAPsj2A= From: "Attila Sipos" To: "Francois Audet" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> > Furthermore, I think this is a bad idea to be honest. I'd rather >> > have the suggestion that someone made that requests with SIPoverTLS >> > be forwarded to SIPoverTLS by proxies. Is that the Proxy-Requires extension idea that you're talking about? I could live with that I guess. But you'd want to make sure that if SIPS couldn't work then SIP over TLS would be tried next then non-secure SIP. Well, I don't know the details but I think we need a way for PSTN to SIP users to get the best security possible. Cheers, Attila >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: 02 November 2006 19:19 >> To: Dean Willis; Attila Sipos >> Cc: IETF SIP List >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >>=20 >>=20 >> =20 >>=20 >> > -----Original Message----- >> > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >> > Sent: Thursday, November 02, 2006 9:44 AM >> > To: Attila Sipos >> > Cc: IETF SIP List >> > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >> >=20 >> >=20 >> > Attila aksed: >> > > So, what you're saying that PSTN gateways should use a >> > > sip: URI with transport=3Dtls? >> > > >> >=20 >> > I think so. >>=20 >> That would require a normative change to RFC 3261 which has=20 >> deprecated transport=3Dtls. >>=20 >> Furthermore, I think this is a bad idea to be honest. I'd rather >> have the suggestion that someone made that requests with SIPoverTLS >> be forwarded to SIPoverTLS by proxies. >>=20 >> I think we have 4 choices for PSTN Gateways: >>=20 >> 1 - SIPS is only valid if all hops are withing a SIP network. PSTN >> gateways would therefore not use SIPS. Gateways to H.323 wouldn't >> either, even if H.323 is secured (same thing for other=20 >> protocols). >>=20 >> 2 - SIPS is valid withing an IP network. H.323 gateways could=20 >> use SIPS, provided they are using an equivalent security level on >> the H.323 side. PSTN gateways gateways would therefore=20 >> not use SIPS. >>=20 >> 3 - SIPS is significant only withing a SIP network, and=20 >> hop-off to PSTN >> or other networks such as H.323 ARE allowed (in the case=20 >> of H.323, >> it would >> require security).=20 >>=20 >> 4 - SIPS is significant only withing a SIP network, and=20 >> hop-off to PSTN >> or other networks such as H.323 ARE allowed and in both=20 >> cases, you >> would require the gateway network to use security.=20 >>=20 >> I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. >>=20 >> There are quite different however.=20 >>=20 >> 1 is my farorite choice if we think that sips has a limitted=20 >> life-span >> and >> will have limited deployment, and will eventually be replaced by >> something better. >>=20 >> 2 is my favorite if we believe sips has a more long-term future. >>=20 >> > > Can we, possibly with Requires, enforce that all hops=20 >> use the TLS? >> >=20 >> > We possibly could, but that would be a new SIP extension, not=20 >> > part of the current sips: specification, and outside of the=20 >> > scope of what could be done with an informational or BCP document. >>=20 >> Right. >>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 16:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfk2b-0001Ho-VR; Thu, 02 Nov 2006 16:24:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfk2a-0001HK-LJ for sip@ietf.org; Thu, 02 Nov 2006 16:24:00 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfk2W-0007Ak-AC for sip@ietf.org; Thu, 02 Nov 2006 16:24:00 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8400D82GS1SU@siemenscomms.co.uk> for sip@ietf.org; Thu, 02 Nov 2006 21:24:01 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG7M4G>; Thu, 02 Nov 2006 21:23:51 +0000 Content-return: allowed Date: Thu, 02 Nov 2006 21:23:49 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Francois Audet , Dean Willis , Attila Sipos Message-id: <50B1CBA96870A34799A506B2313F26670A41117E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, If I understand you correctly, I would favour 3. In other words, if a PSTN gateway receives a SIPS request it should be able to accept it. Any concerns about security within or beyond the PSTN should be dealt with by some other (to be investigated) mechanism. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 02 November 2006 19:19 > To: Dean Willis; Attila Sipos > Cc: IETF SIP List > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, November 02, 2006 9:44 AM > > To: Attila Sipos > > Cc: IETF SIP List > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > > > > > Attila aksed: > > > So, what you're saying that PSTN gateways should use a > > > sip: URI with transport=tls? > > > > > > > I think so. > > That would require a normative change to RFC 3261 which has > deprecated transport=tls. > > Furthermore, I think this is a bad idea to be honest. I'd rather > have the suggestion that someone made that requests with SIPoverTLS > be forwarded to SIPoverTLS by proxies. > > I think we have 4 choices for PSTN Gateways: > > 1 - SIPS is only valid if all hops are withing a SIP network. PSTN > gateways would therefore not use SIPS. Gateways to H.323 wouldn't > either, even if H.323 is secured (same thing for other protocols). > > 2 - SIPS is valid withing an IP network. H.323 gateways could > use SIPS, provided they are using an equivalent security level on > the H.323 side. PSTN gateways gateways would therefore > not use SIPS. > > 3 - SIPS is significant only withing a SIP network, and > hop-off to PSTN > or other networks such as H.323 ARE allowed (in the case of H.323, > it would > require security). > > 4 - SIPS is significant only withing a SIP network, and > hop-off to PSTN > or other networks such as H.323 ARE allowed and in both cases, you > would require the gateway network to use security. > > I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. > > There are quite different however. > > 1 is my farorite choice if we think that sips has a limitted life-span > and > will have limited deployment, and will eventually be replaced by > something better. > > 2 is my favorite if we believe sips has a more long-term future. > > > > Can we, possibly with Requires, enforce that all hops use the TLS? > > > > We possibly could, but that would be a new SIP extension, not > > part of the current sips: specification, and outside of the > > scope of what could be done with an informational or BCP document. > > Right. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 16:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkQU-0006OH-8l; Thu, 02 Nov 2006 16:48:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkQS-0006O8-MK for sip@ietf.org; Thu, 02 Nov 2006 16:48:40 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfkQR-0002Fw-Bp for sip@ietf.org; Thu, 02 Nov 2006 16:48:40 -0500 Received: (from apache@localhost) by figas.ekabal.com (8.11.6/8.11.6) id kA2LmPl13835; Thu, 2 Nov 2006 13:48:25 -0800 From: Rohan Mahy X-Authentication-Warning: figas.ekabal.com: apache set sender to rohan@localhost using -f Received: from 12.151.41.2 (SquirrelMail authenticated user rohan); by figas.ekabal.com with HTTP; Thu, 2 Nov 2006 13:48:24 -0800 (PST) Message-ID: <19980.12.151.41.2.1162504104.squirrel@12.151.41.2> In-Reply-To: <5D44628035C1F54BB415BBD135F5BECF5F4721@esealmw113.eemea.ericsson.se> References: <5D44628035C1F54BB415BBD135F5BECF5F4721@esealmw113.eemea.ericsson.se> Date: Thu, 2 Nov 2006 13:48:24 -0800 (PST) To: "Christer Holmberg \(JO/LMF\)" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List , Rohan Mahy Subject: [Sip] Re: Outbound-05: Indication of number of flows to register X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, We have explicit consensus not to include this functionality in outbound. thanks, -rohan > Hi, > > One issue that has been discussed for outbound is to allow the network > to indicate to the UA how many flows are accepted, and/or how many flows > the user is recommended to register. This value could e.g. be provided > by the registrar. Otherwise, if the maximum number of flows is reached, > registration requests would have to be rejected, which is not good. > > So, my proposal is still that it should be added to outbound. > > Regards, > > Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 17:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkgE-0004bj-9o; Thu, 02 Nov 2006 17:04:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkgD-0004YC-DL for sip@ietf.org; Thu, 02 Nov 2006 17:04:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfkgA-0004fN-Ti for sip@ietf.org; Thu, 02 Nov 2006 17:04:57 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2006 14:04:50 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMr3SUWrRApYh2dsb2JhbACMSQEBCQ4q X-IronPort-AV: i="4.09,381,1157353200"; d="scan'208"; a="338891007:sNHT30729632" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2M4oBO009212; Thu, 2 Nov 2006 14:04:50 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA2M4lbF007821; Thu, 2 Nov 2006 14:04:48 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 17:04:42 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 17:04:42 -0500 Message-ID: <454A6B79.4040102@cisco.com> Date: Thu, 02 Nov 2006 17:04:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <50B1CBA96870A34799A506B2313F26670A41117E@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A41117E@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 22:04:42.0269 (UTC) FILETIME=[E606C4D0:01C6FECA] DKIM-Signature: a=rsa-sha1; q=dns; l=3468; t=1162505090; x=1163369090; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=oiJIMDx+r7ggPTMYTsKQa+7iSLg5YKLypKeszI2I2wtASZoyhflz+N+q/U78fcZVHZ1c/saE 4sscpWxUlQfVRc7iRWM6eg3TRuIys5E0dhNGNHnT9FS199QxxzZ9Pt0X; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: IETF SIP List , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John beat me to it. I also favor 3 (without the special case for H.323) because it is the only one that is really well defined. Once you get beyond this you are talking about the semantics of what is being carried, and we are going need something else to deal with that. Paul Elwell, John wrote: > Francois, > > If I understand you correctly, I would favour 3. In other words, if a PSTN > gateway receives a SIPS request it should be able to accept it. Any concerns > about security within or beyond the PSTN should be dealt with by some other > (to be investigated) mechanism. > > John > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: 02 November 2006 19:19 >> To: Dean Willis; Attila Sipos >> Cc: IETF SIP List >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >> >> >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Thursday, November 02, 2006 9:44 AM >>> To: Attila Sipos >>> Cc: IETF SIP List >>> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >>> >>> >>> Attila aksed: >>>> So, what you're saying that PSTN gateways should use a >>>> sip: URI with transport=tls? >>>> >>> I think so. >> That would require a normative change to RFC 3261 which has >> deprecated transport=tls. >> >> Furthermore, I think this is a bad idea to be honest. I'd rather >> have the suggestion that someone made that requests with SIPoverTLS >> be forwarded to SIPoverTLS by proxies. >> >> I think we have 4 choices for PSTN Gateways: >> >> 1 - SIPS is only valid if all hops are withing a SIP network. PSTN >> gateways would therefore not use SIPS. Gateways to H.323 wouldn't >> either, even if H.323 is secured (same thing for other protocols). >> >> 2 - SIPS is valid withing an IP network. H.323 gateways could >> use SIPS, provided they are using an equivalent security level on >> the H.323 side. PSTN gateways gateways would therefore >> not use SIPS. >> >> 3 - SIPS is significant only withing a SIP network, and >> hop-off to PSTN >> or other networks such as H.323 ARE allowed (in the case of H.323, >> it would >> require security). >> >> 4 - SIPS is significant only withing a SIP network, and >> hop-off to PSTN >> or other networks such as H.323 ARE allowed and in both cases, you >> would require the gateway network to use security. >> >> I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. >> >> There are quite different however. >> >> 1 is my farorite choice if we think that sips has a limitted life-span >> and >> will have limited deployment, and will eventually be replaced by >> something better. >> >> 2 is my favorite if we believe sips has a more long-term future. >> >>>> Can we, possibly with Requires, enforce that all hops use the TLS? >>> We possibly could, but that would be a new SIP extension, not >>> part of the current sips: specification, and outside of the >>> scope of what could be done with an informational or BCP document. >> Right. >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 17:09:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfkia-00060T-97; Thu, 02 Nov 2006 17:07:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkiY-0005uS-OG for sip@ietf.org; Thu, 02 Nov 2006 17:07:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfkiX-00055L-Cg for sip@ietf.org; Thu, 02 Nov 2006 17:07:22 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2006 14:07:18 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADP6SUWrRApPh2dsb2JhbACMSQEBCQ4q X-IronPort-AV: i="4.09,381,1157353200"; d="scan'208"; a="338891664:sNHT97895472" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2M7IFm019991; Thu, 2 Nov 2006 14:07:18 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA2M7HbH009223; Thu, 2 Nov 2006 14:07:18 -0800 (PST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 17:07:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 17:07:16 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E024D31E5@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb+qalAXgx7r2RWReWRdzyK00E7KAACBm5QAAYc5OA= From: "Sanjay Sinha \(sanjsinh\)" To: "Francois Audet" , "Dean Willis" , "Attila Sipos" X-OriginalArrivalTime: 02 Nov 2006 22:07:17.0777 (UTC) FILETIME=[42B76810:01C6FECB] DKIM-Signature: a=rsa-sha1; q=dns; l=2863; t=1162505238; x=1163369238; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:RE=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DNF0oaGeXYLvOSL89WNDCSr2Vjxk=3D; b=DuEalfQmXDKr/m1h2LZTryEbPZAAaYLL7asz+RkwlyZONIXAEm9HXX2ro4us2HidzhyTSZCo nxQgDN4Vi0uyOFawA8NzDxZHPWBx2LavUjZU9YgSYvafmuER9rG+4XwY; Authentication-Results: sj-dkim-5.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 3 & 4 look similar to me. One clarification. When you say pstn gateways should not use sips, what does it mean? Does it mean that for a PSTN-SIP call, it should not use sips even if all hops in sip network are secure? Or does it mean that it acting as a UAS should reject a sips request? If it is later, I agree with what John Elwell said. Sanjay >-----Original Message----- >From: Francois Audet [mailto:audet@nortel.com]=20 >Sent: Thursday, November 02, 2006 2:19 PM >To: Dean Willis; Attila Sipos >Cc: IETF SIP List >Subject: RE: [Sip] A sips: trial balloon for you to shoot down > >=20 > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Thursday, November 02, 2006 9:44 AM >> To: Attila Sipos >> Cc: IETF SIP List >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >>=20 >>=20 >> Attila aksed: >> > So, what you're saying that PSTN gateways should use a >> > sip: URI with transport=3Dtls? >> > >>=20 >> I think so. > >That would require a normative change to RFC 3261 which has=20 >deprecated transport=3Dtls. > >Furthermore, I think this is a bad idea to be honest. I'd=20 >rather have the suggestion that someone made that requests=20 >with SIPoverTLS be forwarded to SIPoverTLS by proxies. > >I think we have 4 choices for PSTN Gateways: > >1 - SIPS is only valid if all hops are withing a SIP network. PSTN > gateways would therefore not use SIPS. Gateways to H.323 wouldn't > either, even if H.323 is secured (same thing for other protocols). > >2 - SIPS is valid withing an IP network. H.323 gateways could=20 > use SIPS, provided they are using an equivalent security level on > the H.323 side. PSTN gateways gateways would therefore not=20 >use SIPS. > >3 - SIPS is significant only withing a SIP network, and hop-off to PSTN > or other networks such as H.323 ARE allowed (in the case=20 >of H.323, it would > require security).=20 > >4 - SIPS is significant only withing a SIP network, and hop-off to PSTN > or other networks such as H.323 ARE allowed and in both cases, you > would require the gateway network to use security.=20 > >I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. > >There are quite different however.=20 > >1 is my farorite choice if we think that sips has a limitted=20 >life-span and will have limited deployment, and will=20 >eventually be replaced by something better. > >2 is my favorite if we believe sips has a more long-term future. > >> > Can we, possibly with Requires, enforce that all hops use the TLS? >>=20 >> We possibly could, but that would be a new SIP extension,=20 >not part of=20 >> the current sips: specification, and outside of the scope of what=20 >> could be done with an informational or BCP document. > >Right. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 17:42:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflDR-0004UZ-Mk; Thu, 02 Nov 2006 17:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflDP-0004UH-NV for sip@ietf.org; Thu, 02 Nov 2006 17:39:15 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GflDO-0001lo-9O for sip@ietf.org; Thu, 02 Nov 2006 17:39:15 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GflD5-00032I-1X; Thu, 02 Nov 2006 16:38:55 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Elwell, John'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 17:38:58 -0500 Message-ID: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb+y3O5wFePpKodS76XDfN9UdyaQQAAwEpA In-Reply-To: <454A6B79.4040102@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 'IETF SIP List' , 'Francois Audet' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess the problem here is whether you consider the PSTN to be secure, in the sense of TLS, expressed in Dean's proposed wording. If you do, then what you propose is consistent. Can you give me a use case where sips does something useful when one end is on the PSTN? I don't think anyone believes the PSTN is secure in anything close to TLS level security. I sort of understand the issue of the IETF can only control the sip path, and what happens beyond is not in its purview. Using that to create meaningless mechanisms isn't helpful IMO. Let's use the example cited a little while ago: a MESSAGE. You clearly could, at a gateway, convert that to SMS. Does it make ANY sense to call that secure if it was TLS from UAC to a gateway, and then over a GSM network to a handset? Isn't there a substantive difference between that and TLS protected MESSAGE all the way to the handset? What earthly good does it do to get sips to succeed if the last hop is not secure? I think if the gateway knows its not the end of the signaling, then it has to fail sips if it can't maintain TLS. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, November 02, 2006 5:05 PM > To: Elwell, John > Cc: IETF SIP List; Francois Audet; Dean Willis > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > John beat me to it. I also favor 3 (without the special case for H.323) > because it is the only one that is really well defined. Once you get > beyond this you are talking about the semantics of what is being > carried, and we are going need something else to deal with that. > > Paul > > Elwell, John wrote: > > Francois, > > > > If I understand you correctly, I would favour 3. In other words, if a > PSTN > > gateway receives a SIPS request it should be able to accept it. Any > concerns > > about security within or beyond the PSTN should be dealt with by some > other > > (to be investigated) mechanism. > > > > John > > > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> Sent: 02 November 2006 19:19 > >> To: Dean Willis; Attila Sipos > >> Cc: IETF SIP List > >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down > >> > >> > >> > >>> -----Original Message----- > >>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>> Sent: Thursday, November 02, 2006 9:44 AM > >>> To: Attila Sipos > >>> Cc: IETF SIP List > >>> Subject: Re: [Sip] A sips: trial balloon for you to shoot down > >>> > >>> > >>> Attila aksed: > >>>> So, what you're saying that PSTN gateways should use a > >>>> sip: URI with transport=tls? > >>>> > >>> I think so. > >> That would require a normative change to RFC 3261 which has > >> deprecated transport=tls. > >> > >> Furthermore, I think this is a bad idea to be honest. I'd rather > >> have the suggestion that someone made that requests with SIPoverTLS > >> be forwarded to SIPoverTLS by proxies. > >> > >> I think we have 4 choices for PSTN Gateways: > >> > >> 1 - SIPS is only valid if all hops are withing a SIP network. PSTN > >> gateways would therefore not use SIPS. Gateways to H.323 wouldn't > >> either, even if H.323 is secured (same thing for other protocols). > >> > >> 2 - SIPS is valid withing an IP network. H.323 gateways could > >> use SIPS, provided they are using an equivalent security level on > >> the H.323 side. PSTN gateways gateways would therefore > >> not use SIPS. > >> > >> 3 - SIPS is significant only withing a SIP network, and > >> hop-off to PSTN > >> or other networks such as H.323 ARE allowed (in the case of H.323, > >> it would > >> require security). > >> > >> 4 - SIPS is significant only withing a SIP network, and > >> hop-off to PSTN > >> or other networks such as H.323 ARE allowed and in both cases, you > >> would require the gateway network to use security. > >> > >> I think Brian Rosen favored 4. Personally, I prefer either 1 or 2. > >> > >> There are quite different however. > >> > >> 1 is my farorite choice if we think that sips has a limitted life-span > >> and > >> will have limited deployment, and will eventually be replaced by > >> something better. > >> > >> 2 is my favorite if we believe sips has a more long-term future. > >> > >>>> Can we, possibly with Requires, enforce that all hops use the TLS? > >>> We possibly could, but that would be a new SIP extension, not > >>> part of the current sips: specification, and outside of the > >>> scope of what could be done with an informational or BCP document. > >> Right. > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 18:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gflru-0000gE-Jk; Thu, 02 Nov 2006 18:21:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gflrt-0000g8-Nv for sip@ietf.org; Thu, 02 Nov 2006 18:21:05 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gflrl-0007pk-9w for sip@ietf.org; Thu, 02 Nov 2006 18:21:05 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7762E1B7; Fri, 3 Nov 2006 00:20:48 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 00:20:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Nov 2006 00:20:47 +0100 Message-ID: <5D44628035C1F54BB415BBD135F5BECF5F4F42@esealmw113.eemea.ericsson.se> In-Reply-To: <19980.12.151.41.2.1162504104.squirrel@12.151.41.2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: Indication of number of flows to register Thread-Index: Acb+1JBrznBpjXwYTCqQ/nJxD0JeAgAADMvQ From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 02 Nov 2006 23:20:48.0409 (UTC) FILETIME=[87A87090:01C6FED5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List Subject: [Sip] RE: Outbound-05: Indication of number of flows to register X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >We have explicit consensus not to include this functionality in outbound. We do? When was that consensus reached? At least not as part of the "Re: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER" mail thread, as far as I am aware. And, no matter if we have that indicator or not, which error code shall the registrar use if a user has reached the maximum number of flows, and the registrar does not accept more flows? Regards, Christer > > Hi, > > > > One issue that has been discussed for outbound is to allow=20 > the network=20 > > to indicate to the UA how many flows are accepted, and/or how many=20 > > flows the user is recommended to register. This value could e.g. be=20 > > provided by the registrar. Otherwise, if the maximum number=20 > of flows=20 > > is reached, registration requests would have to be=20 > rejected, which is not good. > > > > So, my proposal is still that it should be added to outbound. > > > > Regards, > > > > Christer > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 19:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfnIJ-0001Gs-Ap; Thu, 02 Nov 2006 19:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfnIH-0001FF-QZ for sip@ietf.org; Thu, 02 Nov 2006 19:52:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfnIE-0004y5-Fv for sip@ietf.org; Thu, 02 Nov 2006 19:52:25 -0500 Received: from [192.168.1.5] (cpe-24-160-121-70.houston.res.rr.com [24.160.121.70]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA2NtvwE028685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 17:55:57 -0600 In-Reply-To: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 18:52:19 -0600 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 2, 2006, at 4:38 PM, Brian Rosen wrote: > Let's use the example cited a little while ago: a MESSAGE. You > clearly > could, at a gateway, convert that to SMS. Does it make ANY sense > to call > that secure if it was TLS from UAC to a gateway, and then over a > GSM network > to a handset? Isn't there a substantive difference between that > and TLS > protected MESSAGE all the way to the handset? What earthly good > does it do > to get sips to succeed if the last hop is not secure? I think if the > gateway knows its not the end of the signaling, then it has to fail > sips if > it can't maintain TLS. Ouch. Good example. I was about to endorse #3, but I think you're onto something here. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 23:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfqVU-0002G5-SU; Thu, 02 Nov 2006 23:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfqVS-0002Ez-VT for sip@ietf.org; Thu, 02 Nov 2006 23:18:14 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfqVR-0006Gc-KU for sip@ietf.org; Thu, 02 Nov 2006 23:18:14 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id A2F70758; Thu, 02 Nov 2006 23:17:59 -0500 From: "Hadriel Kaplan" To: "'Brian Rosen'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 23:17:47 -0500 Message-ID: <026d01c6feff$04ed6460$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb+y3O5wFePpKodS76XDfN9UdyaQQAAwEpAAAmUaUA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So far the explanation/argument of sips has been that sips is not a synonym for human-to-human security. It does not provide a lock icon. It is nothing more than a mandate that each sip hop use TLS. It is just a uri scheme, which behaves like a require/proxy-require for transport=tls. It is nothing more than that. Your proposal is that it become more than a uri scheme for sip; that it become a human-level request for TLS or TLS-level of "secure" (whatever that is defined as), regardless of the protocol. That it reaches something past the UAS, in some higher plane. Almost like a require that the message headers (and really the body) not leave a cpu. Or maybe a new scheme called tls. :) Don't get me wrong - I understand what you mean and why, but SIPS isn't it. It would be a significant divergence from 3261 to define a sips uri scheme as having such a property, to reach beyond the SIPS UAS, IMO. The uri in the sips request is not even the identifier of the SMS receiver. It is the identifier of the gateway. If you reached that gateway using TLS, then you succeeded. Does any URI or scheme mean more? Http, https, email, ftp, etc. all identify the server/end of the protocol, not something beyond. (an interesting one would be tel - if there was a tels, that is) I think what you're really looking for is a new thing. -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 02, 2006 5:39 PM > To: 'Paul Kyzivat'; 'Elwell, John' > Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > I guess the problem here is whether you consider the PSTN to be secure, in > the sense of TLS, expressed in Dean's proposed wording. If you do, then > what you propose is consistent. > > Can you give me a use case where sips does something useful when one end > is > on the PSTN? > > I don't think anyone believes the PSTN is secure in anything close to TLS > level security. I sort of understand the issue of the IETF can only > control > the sip path, and what happens beyond is not in its purview. Using that > to > create meaningless mechanisms isn't helpful IMO. > > Let's use the example cited a little while ago: a MESSAGE. You clearly > could, at a gateway, convert that to SMS. Does it make ANY sense to call > that secure if it was TLS from UAC to a gateway, and then over a GSM > network > to a handset? Isn't there a substantive difference between that and TLS > protected MESSAGE all the way to the handset? What earthly good does it > do > to get sips to succeed if the last hop is not secure? I think if the > gateway knows its not the end of the signaling, then it has to fail sips > if > it can't maintain TLS. > > Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 02 23:53:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfr1E-0001hJ-DZ; Thu, 02 Nov 2006 23:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfr1C-0001Uf-OM for sip@ietf.org; Thu, 02 Nov 2006 23:51:02 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfr1B-00038i-GG for sip@ietf.org; Thu, 02 Nov 2006 23:51:02 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id AAA50428; Thu, 02 Nov 2006 23:50:45 -0500 From: "Hadriel Kaplan" To: "'Brian Rosen'" , "'Paul Kyzivat'" , "'Elwell, John'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Thu, 2 Nov 2006 23:50:32 -0500 Message-ID: <027501c6ff03$98976040$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb+y3O5wFePpKodS76XDfN9UdyaQQAAwEpAAAwykCA= X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'IETF SIP List' , 'Francois Audet' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 02, 2006 5:39 PM > > What earthly good does it do > to get sips to succeed if the last hop is not secure? > I think if the > gateway knows its not the end of the signaling, then it has to fail sips > if it can't maintain TLS. But that sip-sms gateway is the end of the signaling. The end of SIP signaling altogether. The body contents happened to get transferred in another protocol though. But ok, so let's say the MESSAGE gateway sends it over email (not unlikely). It happens to be able to get an SMTP over TLS connection to your email server. So it can do it, right? Little did it know the end user uses pop3 in the clear to pull down email from that server, or that server then forwarded it to an SMS gateway. Or your sips-based Invite audio session was to a sips voicemail server, but the user used sip to hear your voicemail. What earthly good was done? ;) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 00:03:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrB0-0001i3-U9; Fri, 03 Nov 2006 00:01:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrAz-0001fK-HH for sip@ietf.org; Fri, 03 Nov 2006 00:01:09 -0500 Received: from m13-61.163.com ([220.181.13.61]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfrAt-0004lf-2m for sip@ietf.org; Fri, 03 Nov 2006 00:01:09 -0500 Received: from 59.77.18.200 ( 59.77.18.200 [59.77.18.200] ) by webmail-app61 (Coremail) ; Fri, 3 Nov 2006 13:00:41 +0800 (CST) MIME-Version: 1.0 Message-ID: <454ACCF9.00000D.13912@bj163app61.163.com> Date: Fri, 3 Nov 2006 13:00:41 +0800 (CST) From: "sakura210" To: sip@ietf.org X-Priority: 3 X-Originating-IP: [59.77.18.200] X-Mailer: 163com X-Spam-Score: 2.1 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] seek help about "multicast in SIP" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1008602886==" Errors-To: sip-bounces@ietf.org --===============1008602886== Content-Type: Multipart/Alternative; boundary="Boundary-=_NPvqIjfZdXtBpTrGvRcleeBNZmTk" --Boundary-=_NPvqIjfZdXtBpTrGvRcleeBNZmTk Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit hello I am a new comer in the field of SIP and having some trouble in getting the drafts or other papers about "multicast or broadcast in SIP". Could you tell me where to get the sources on the title? I am learning how multicasting works in SIP now,and so eager to study this principles. Thank you for reading my words.I am looking forward to hearing from you. vivi --Boundary-=_NPvqIjfZdXtBpTrGvRcleeBNZmTk Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
hello
    I am a new comer in the field of SIP and hav= ing some trouble in getting the drafts or other papers about "multicast o= r broadcast in SIP".
    Could you tell me where to get the sources on the= title? I am learning how multicasting works in SIP now,and so eager= to study this principles.
    Thank you for reading my words.I am looking forwa= rd to hearing from you.
         
           &n= bsp;           &nb= sp;   vivi







=093G =CA=B1 =B4=FA =C0=B4= =C1=D9 =C1=CB=A3=AC=BC=E1 =BE=F6 =B6=D4 =B4=AB =CD=B3 =D3=CA =CF=E4 =CB=B5= =B2=BB =A3=A1 =09
=09 =D0=C2 =D2=BB =B4=FA =BC=AB =CB=D9 3G =D3= =CA =CF=E4 =C9=C1 =C1=C1 =B5=C7 =B3=A1 =A3=AC280 =D5=D7 =CD=F8 =C5=CC =C3= =E2 =B7=D1 =CB=CD =A3=A1 =B5=E3 =BB=F7 =B4=CB =B4=A6 =D7=A2 =B2=E1 --Boundary-=_NPvqIjfZdXtBpTrGvRcleeBNZmTk-- --===============1008602886== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1008602886==-- From sip-bounces@ietf.org Fri Nov 03 02:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GftDE-0007Ke-2M; Fri, 03 Nov 2006 02:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GftDC-0007KT-J3 for sip@ietf.org; Fri, 03 Nov 2006 02:11:34 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GftD8-0000I7-If for sip@ietf.org; Fri, 03 Nov 2006 02:11:33 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8500I3H7Z974@siemenscomms.co.uk> for sip@ietf.org; Fri, 03 Nov 2006 07:11:33 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG7PDR>; Fri, 03 Nov 2006 07:11:23 +0000 Content-return: allowed Date: Fri, 03 Nov 2006 07:11:22 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Brian Rosen , 'Paul Kyzivat' Message-id: <50B1CBA96870A34799A506B2313F26670A4111D4@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'IETF SIP List' , 'Francois Audet' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, > Can you give me a use case where sips does something useful > when one end is > on the PSTN? You could use SIPS to transfer something securely, in the SIP request, as far as the UAS, for example SDescriptions. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 03:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfuOD-0005mP-FM; Fri, 03 Nov 2006 03:27:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfuOC-0005mC-1D for sip@ietf.org; Fri, 03 Nov 2006 03:27:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfuO9-0000cn-Mi for sip@ietf.org; Fri, 03 Nov 2006 03:27:00 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2006 00:26:57 -0800 X-IronPort-AV: i="4.09,383,1157353200"; d="scan'208"; a="339057143:sNHT45829440" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA38QvOl017941 for ; Fri, 3 Nov 2006 00:26:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA38QubF028828 for ; Fri, 3 Nov 2006 00:26:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Nov 2006 00:26:56 -0800 Received: from [192.168.1.3] ([10.21.123.172]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 00:26:55 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 3 Nov 2006 00:26:57 -0800 To: SIP X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Nov 2006 08:26:55.0657 (UTC) FILETIME=[D275B190:01C6FF21] DKIM-Signature: a=rsa-sha1; q=dns; l=319; t=1162542417; x=1163406417; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-ietf-sip-gruu-11=20-=20Gruuvy; X=v=3Dcisco.com=3B=20h=3DutQpmLoahfBDxzZ5Ca9KcPtpnko=3D; b=ROvG/ijzKyj6hpHqvOUOHFrmU5Nf2to5q4VyP5FPmEzbMyDq3/cR+iigaN4YFYer+Ydm0keg 5WFyJUrbsPTFCTdAUYi1wBMrcouagk+hUZPz9HBF2vyAlaG8FwwTmBhw; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Sip] draft-ietf-sip-gruu-11 - Gruuvy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I went thought my long list of requirements, desires, hoops to jump thought, and swamps to swim through that various folks have put up as opportunities for GRUU to "build character". This version seems to address all of them. Congratulations. I hope we get to call this one done real soon now. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 04:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfuvk-0003Jp-Dw; Fri, 03 Nov 2006 04:01:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfuvi-0003JA-Gx for sip@ietf.org; Fri, 03 Nov 2006 04:01:38 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfuvh-0004EF-2E for sip@ietf.org; Fri, 03 Nov 2006 04:01:38 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA391Jnx031231; Fri, 3 Nov 2006 11:01:23 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 11:01:18 +0200 Received: from [172.21.36.67] ([172.21.36.67]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Nov 2006 11:01:18 +0200 Message-ID: <454B055D.4090505@nokia.com> Date: Fri, 03 Nov 2006 11:01:17 +0200 From: Aki Niemi Organization: Nokia-NRC/Helsinki User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: ext Brian Rosen Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> In-Reply-To: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2006 09:01:18.0713 (UTC) FILETIME=[A0230E90:01C6FF26] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061103110126-787DFBB0-1824E3B1/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Brian Rosen kirjoitti: > I guess the problem here is whether you consider the PSTN to be secure, in > the sense of TLS, expressed in Dean's proposed wording. If you do, then > what you propose is consistent. > > Can you give me a use case where sips does something useful when one end is > on the PSTN? > > I don't think anyone believes the PSTN is secure in anything close to TLS > level security. I sort of understand the issue of the IETF can only control > the sip path, and what happens beyond is not in its purview. Using that to > create meaningless mechanisms isn't helpful IMO. What do you mean by "TLS level security"? AFAICS, sips is still meant to work as a hop-by-hop security mechanism, much like how the PSTN works. > Let's use the example cited a little while ago: a MESSAGE. You clearly > could, at a gateway, convert that to SMS. Does it make ANY sense to call > that secure if it was TLS from UAC to a gateway, and then over a GSM network > to a handset? Isn't there a substantive difference between that and TLS > protected MESSAGE all the way to the handset? What earthly good does it do > to get sips to succeed if the last hop is not secure? I think if the > gateway knows its not the end of the signaling, then it has to fail sips if > it can't maintain TLS. Can you explain how this would be any different for a web form, used via an https URL, that feeds a message as an SMS into the GSM cloud? i don't see the HTTP community spending effort in figuring out how to deal with that type of corner cases. I think this particular monkey-wrench is not particularly interesting, and the only thing the IETF *can* do is something along the lines of #3 in Francois' note. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 07:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfyRR-0003NO-TR; Fri, 03 Nov 2006 07:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfyRP-0003Je-RT for sip@ietf.org; Fri, 03 Nov 2006 07:46:35 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GftL0-0001iD-6N for sip@ietf.org; Fri, 03 Nov 2006 02:19:39 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8500I748CZ74@siemenscomms.co.uk> for sip@ietf.org; Fri, 03 Nov 2006 07:19:47 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG7PHA>; Fri, 03 Nov 2006 07:19:37 +0000 Content-return: allowed Date: Fri, 03 Nov 2006 07:19:36 +0000 From: "Elwell, John" Subject: RE: [Sip] A sips: trial balloon for you to shoot down To: Hadriel Kaplan , 'Brian Rosen' Message-id: <50B1CBA96870A34799A506B2313F26670A4111D5@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, Yes, and furthermore this ties in nicely with the concepts in draft-rosenberg-rai-phones-numbers-00, which draws a big distinction between a tel URI and sip/sips URI. A sip/sips URI in a Request-URI addresses the SIP resource to which you want your request to be routed, so addressing to sips:+123456789@example.com;user=phone is effectively addressing a gateway in example.com if +123456789 cannot be reached in the SIP network. John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 03 November 2006 04:18 > To: 'Brian Rosen' > Cc: 'IETF SIP List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > So far the explanation/argument of sips has been that sips is > not a synonym > for human-to-human security. It does not provide a lock icon. It is > nothing more than a mandate that each sip hop use TLS. It is > just a uri > scheme, which behaves like a require/proxy-require for > transport=tls. It is > nothing more than that. > > Your proposal is that it become more than a uri scheme for > sip; that it > become a human-level request for TLS or TLS-level of "secure" > (whatever that > is defined as), regardless of the protocol. That it reaches > something past > the UAS, in some higher plane. Almost like a require that the message > headers (and really the body) not leave a cpu. Or maybe a > new scheme called > tls. :) > > Don't get me wrong - I understand what you mean and why, but > SIPS isn't it. > It would be a significant divergence from 3261 to define a > sips uri scheme > as having such a property, to reach beyond the SIPS UAS, IMO. > The uri in > the sips request is not even the identifier of the SMS > receiver. It is the > identifier of the gateway. If you reached that gateway using > TLS, then you > succeeded. > > Does any URI or scheme mean more? Http, https, email, ftp, etc. all > identify the server/end of the protocol, not something beyond. (an > interesting one would be tel - if there was a tels, that is) > > I think what you're really looking for is a new thing. > > -hadriel > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 02, 2006 5:39 PM > > To: 'Paul Kyzivat'; 'Elwell, John' > > Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' > > Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > > > I guess the problem here is whether you consider the PSTN > to be secure, in > > the sense of TLS, expressed in Dean's proposed wording. If > you do, then > > what you propose is consistent. > > > > Can you give me a use case where sips does something useful > when one end > > is > > on the PSTN? > > > > I don't think anyone believes the PSTN is secure in > anything close to TLS > > level security. I sort of understand the issue of the IETF can only > > control > > the sip path, and what happens beyond is not in its > purview. Using that > > to > > create meaningless mechanisms isn't helpful IMO. > > > > Let's use the example cited a little while ago: a MESSAGE. > You clearly > > could, at a gateway, convert that to SMS. Does it make ANY > sense to call > > that secure if it was TLS from UAC to a gateway, and then over a GSM > > network > > to a handset? Isn't there a substantive difference between > that and TLS > > protected MESSAGE all the way to the handset? What earthly > good does it > > do > > to get sips to succeed if the last hop is not secure? I > think if the > > gateway knows its not the end of the signaling, then it has > to fail sips > > if > > it can't maintain TLS. > > > > Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 09:10:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfzfi-00076u-Vn; Fri, 03 Nov 2006 09:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfzfh-00070X-22 for sip@ietf.org; Fri, 03 Nov 2006 09:05:25 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfzeg-0000kS-Rz for sip@ietf.org; Fri, 03 Nov 2006 09:04:27 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2006 09:04:22 -0500 X-IronPort-AV: i="4.09,384,1157342400"; d="scan'208"; a="108631233:sNHT593413844" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3E4M77021271; Fri, 3 Nov 2006 09:04:22 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA3E4LDM020531; Fri, 3 Nov 2006 09:04:21 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 09:04:21 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 09:04:20 -0500 Message-ID: <454B4C64.1040704@cisco.com> Date: Fri, 03 Nov 2006 09:04:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <026d01c6feff$04ed6460$0500a8c0@acmepacket.com> In-Reply-To: <026d01c6feff$04ed6460$0500a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2006 14:04:20.0979 (UTC) FILETIME=[F59CAC30:01C6FF50] DKIM-Signature: a=rsa-sha1; q=dns; l=4297; t=1162562662; x=1163426662; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:Hadriel=20Kaplan=20; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=p/2mYRH9isz42eFLPPWKOV2c3b/335xVpxChL1aVurICTjFmwoRun7ElIKoYpQN1BDGdcf/q csorAE7/17tj1ZPtRCbJBKvbU/+VWH+6qd0fcApaibKAOR8/DuatmniO; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This time Hadriel gave the answer I would have given. To answer Brian directly, no I don't think the PSTN is secure in the sense of TLS. But it does have some security properties that, at least on average, are better than what one gets with unsecured sip over the internet. Using SIPS sips to reach a GW may provide a useful tool for creating an end to end session that is no worse than a pure PSTN session. That in itself is worth something. The same is true if it is a MESSAGE gateway to SMS. The SIPS itself doesn't guarantee this. It is only SIPS in combination with the UAs and what they do that guarantees that. But everything that extends beyond the UAs (including a UA that drives a UI) has such a dependency. (I find the positions in this discussion to be very interesting. I find I am aligned with those I have often have had differences with in the past, and arguing with those I typically more often agree with. I have no idea what that means.) Paul Hadriel Kaplan wrote: > So far the explanation/argument of sips has been that sips is not a synonym > for human-to-human security. It does not provide a lock icon. It is > nothing more than a mandate that each sip hop use TLS. It is just a uri > scheme, which behaves like a require/proxy-require for transport=tls. It is > nothing more than that. > > Your proposal is that it become more than a uri scheme for sip; that it > become a human-level request for TLS or TLS-level of "secure" (whatever that > is defined as), regardless of the protocol. That it reaches something past > the UAS, in some higher plane. Almost like a require that the message > headers (and really the body) not leave a cpu. Or maybe a new scheme called > tls. :) > > Don't get me wrong - I understand what you mean and why, but SIPS isn't it. > It would be a significant divergence from 3261 to define a sips uri scheme > as having such a property, to reach beyond the SIPS UAS, IMO. The uri in > the sips request is not even the identifier of the SMS receiver. It is the > identifier of the gateway. If you reached that gateway using TLS, then you > succeeded. > > Does any URI or scheme mean more? Http, https, email, ftp, etc. all > identify the server/end of the protocol, not something beyond. (an > interesting one would be tel - if there was a tels, that is) > > I think what you're really looking for is a new thing. > > -hadriel > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, November 02, 2006 5:39 PM >> To: 'Paul Kyzivat'; 'Elwell, John' >> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >> >> I guess the problem here is whether you consider the PSTN to be secure, in >> the sense of TLS, expressed in Dean's proposed wording. If you do, then >> what you propose is consistent. >> >> Can you give me a use case where sips does something useful when one end >> is >> on the PSTN? >> >> I don't think anyone believes the PSTN is secure in anything close to TLS >> level security. I sort of understand the issue of the IETF can only >> control >> the sip path, and what happens beyond is not in its purview. Using that >> to >> create meaningless mechanisms isn't helpful IMO. >> >> Let's use the example cited a little while ago: a MESSAGE. You clearly >> could, at a gateway, convert that to SMS. Does it make ANY sense to call >> that secure if it was TLS from UAC to a gateway, and then over a GSM >> network >> to a handset? Isn't there a substantive difference between that and TLS >> protected MESSAGE all the way to the handset? What earthly good does it >> do >> to get sips to succeed if the last hop is not secure? I think if the >> gateway knows its not the end of the signaling, then it has to fail sips >> if >> it can't maintain TLS. >> >> Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 11:36:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1yz-0007ai-Mp; Fri, 03 Nov 2006 11:33:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1yy-0007ad-EY for sip@ietf.org; Fri, 03 Nov 2006 11:33:28 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg1yt-0002rX-Vq for sip@ietf.org; Fri, 03 Nov 2006 11:33:28 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gg1yk-0000QX-7E; Fri, 03 Nov 2006 10:33:16 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Hadriel Kaplan'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 11:33:14 -0500 Message-ID: <047f01c6ff65$c6120f90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb/UPiaK8M8U0dGShGwa/J+z7bU9AAE/CYg In-Reply-To: <454B4C64.1040704@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The proposal Dean made included this text: >Where TLS is not used, the implementor MUST exercise a high level of >caution to provide adequate security and MUST preserve operationally >equivalent protection of message integrity, privacy, and participant >identity (authentication). A PSTN gateway does not do that. Again, as has been said, we'll all agree that sips is not sufficient to solve all of our security problems, and I readily see that there are circumstances where the security in the PSTN is considered sufficient. I claim that's not sips. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, November 03, 2006 9:04 AM > To: Hadriel Kaplan > Cc: 'Brian Rosen'; 'IETF SIP List' > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > This time Hadriel gave the answer I would have given. > > To answer Brian directly, no I don't think the PSTN is secure in the > sense of TLS. But it does have some security properties that, at least > on average, are better than what one gets with unsecured sip over the > internet. Using SIPS sips to reach a GW may provide a useful tool for > creating an end to end session that is no worse than a pure PSTN > session. That in itself is worth something. The same is true if it is a > MESSAGE gateway to SMS. > > The SIPS itself doesn't guarantee this. It is only SIPS in combination > with the UAs and what they do that guarantees that. But everything that > extends beyond the UAs (including a UA that drives a UI) has such a > dependency. > > (I find the positions in this discussion to be very interesting. I find > I am aligned with those I have often have had differences with in the > past, and arguing with those I typically more often agree with. I have > no idea what that means.) > > Paul > > Hadriel Kaplan wrote: > > So far the explanation/argument of sips has been that sips is not a > synonym > > for human-to-human security. It does not provide a lock icon. It is > > nothing more than a mandate that each sip hop use TLS. It is just a uri > > scheme, which behaves like a require/proxy-require for transport=tls. > It is > > nothing more than that. > > > > Your proposal is that it become more than a uri scheme for sip; that it > > become a human-level request for TLS or TLS-level of "secure" (whatever > that > > is defined as), regardless of the protocol. That it reaches something > past > > the UAS, in some higher plane. Almost like a require that the message > > headers (and really the body) not leave a cpu. Or maybe a new scheme > called > > tls. :) > > > > Don't get me wrong - I understand what you mean and why, but SIPS isn't > it. > > It would be a significant divergence from 3261 to define a sips uri > scheme > > as having such a property, to reach beyond the SIPS UAS, IMO. The uri > in > > the sips request is not even the identifier of the SMS receiver. It is > the > > identifier of the gateway. If you reached that gateway using TLS, then > you > > succeeded. > > > > Does any URI or scheme mean more? Http, https, email, ftp, etc. all > > identify the server/end of the protocol, not something beyond. (an > > interesting one would be tel - if there was a tels, that is) > > > > I think what you're really looking for is a new thing. > > > > -hadriel > > > > > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Thursday, November 02, 2006 5:39 PM > >> To: 'Paul Kyzivat'; 'Elwell, John' > >> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' > >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down > >> > >> I guess the problem here is whether you consider the PSTN to be secure, > in > >> the sense of TLS, expressed in Dean's proposed wording. If you do, > then > >> what you propose is consistent. > >> > >> Can you give me a use case where sips does something useful when one > end > >> is > >> on the PSTN? > >> > >> I don't think anyone believes the PSTN is secure in anything close to > TLS > >> level security. I sort of understand the issue of the IETF can only > >> control > >> the sip path, and what happens beyond is not in its purview. Using > that > >> to > >> create meaningless mechanisms isn't helpful IMO. > >> > >> Let's use the example cited a little while ago: a MESSAGE. You clearly > >> could, at a gateway, convert that to SMS. Does it make ANY sense to > call > >> that secure if it was TLS from UAC to a gateway, and then over a GSM > >> network > >> to a handset? Isn't there a substantive difference between that and > TLS > >> protected MESSAGE all the way to the handset? What earthly good does > it > >> do > >> to get sips to succeed if the last hop is not secure? I think if the > >> gateway knows its not the end of the signaling, then it has to fail > sips > >> if > >> it can't maintain TLS. > >> > >> Brian > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 11:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg28R-00014L-Cs; Fri, 03 Nov 2006 11:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg28P-000146-Fl for sip@ietf.org; Fri, 03 Nov 2006 11:43:13 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg28J-0003oL-VK for sip@ietf.org; Fri, 03 Nov 2006 11:43:13 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 08:43:07 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="754378726:sNHT50284524" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3Gh7bm005189; Fri, 3 Nov 2006 08:43:07 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA3Gh7Ao003047; Fri, 3 Nov 2006 08:43:07 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn4-499.cisco.com [10.21.81.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA3GU5cC014038; Fri, 3 Nov 2006 08:30:07 -0800 Message-ID: <454B719E.6000507@cisco.com> Date: Fri, 03 Nov 2006 08:43:10 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> <706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com> In-Reply-To: <706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1381; t=1162572187; x=1163436187; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DfUTxn6IgjLQQzti8C+nkZkpuBz4=3D; b=kDXywEdSQiBSiLaaxIwZSCF5Y/hQVAFrFjFJuitxgSerOIVCXA6Ch2zV1kMK5mpVuMK2rtjd 88rW+edOs/ybm/i/1WNOi2wdou9ZN9uCJIff8YNVX0e5+v2Kl29H7Fmj; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 2, 2006, at 4:38 PM, Brian Rosen wrote: > >> Let's use the example cited a little while ago: a MESSAGE. You clearly >> could, at a gateway, convert that to SMS. Does it make ANY sense to >> call >> that secure if it was TLS from UAC to a gateway, and then over a GSM >> network >> to a handset? Isn't there a substantive difference between that and >> TLS >> protected MESSAGE all the way to the handset? What earthly good >> does it do >> to get sips to succeed if the last hop is not secure? I think if the >> gateway knows its not the end of the signaling, then it has to fail >> sips if >> it can't maintain TLS. > > > > Ouch. Good example. I was about to endorse #3, but I think you're > onto something here. I find all of this slippery slopery rather fascinating. On the one hand, I'm being told that SIPS is a crappy stopgap and that I shouldn't be too worried about the trust implications of evil middle proxies, and other hand I see this amazing amount of hand-wringing about what happens when it's outside of the realm of SIP. Riddle me this: I assume you have no problem with a SIPS session terminating on my host and that I blat out the payload to a terminal window? What happens if the terminal window is, oh say, at Times Square via a handy VNC connection? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 11:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg28k-0001Kq-BH; Fri, 03 Nov 2006 11:43:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg28i-0001Kl-Q1 for sip@ietf.org; Fri, 03 Nov 2006 11:43:32 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg28e-0003q8-B8 for sip@ietf.org; Fri, 03 Nov 2006 11:43:32 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2006 11:43:28 -0500 X-IronPort-AV: i="4.09,386,1157342400"; d="scan'208"; a="108653650:sNHT62321596" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3GhSE5032527; Fri, 3 Nov 2006 11:43:28 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA3GhRYL016114; Fri, 3 Nov 2006 11:43:27 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 11:43:27 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 11:43:27 -0500 Message-ID: <454B71AE.2070006@cisco.com> Date: Fri, 03 Nov 2006 11:43:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <047f01c6ff65$c6120f90$640fa8c0@cis.neustar.com> In-Reply-To: <047f01c6ff65$c6120f90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2006 16:43:27.0285 (UTC) FILETIME=[2FA75E50:01C6FF67] DKIM-Signature: a=rsa-sha1; q=dns; l=6215; t=1162572208; x=1163436208; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:Brian=20Rosen=20; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=jmBWgRcf97z0tqEuzBMbqBpzO+iZVoVGZPGZnyDdhd4WkKTA10+0J6hW1NN6vU8XvUqKJCpd SNpzDYukPJmpLroDkaS+n4XeGarLKBrBHGFfKRm7v3bX2jvFba/UfYje; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > The proposal Dean made included this text: >> Where TLS is not used, the implementor MUST exercise a high level of >> caution to provide adequate security and MUST preserve operationally >> equivalent protection of message integrity, privacy, and participant >> identity (authentication). > > A PSTN gateway does not do that. And I'm not agreeing with that. I think the UA in this case does what it does. It may do something special if sips was used, and it may not. While what it does may be important to the sender at the other end, it just doesn't have anything to do with SIPS. As others have pointed out, this is just like HTTPS. There is nothing in the specification of HTPPS that requires the HTTPS server to treat the information it receives securely. Based on your criteria, if a server receives a MESSAGE over SIPS, what may it do with it, and what may it not do with it? Can it store the message on a file server? Does it matter what the security of the file server is? How is storing it on an insecure file server any better than sending it via SMS? Paul > Again, as has been said, we'll all agree that sips is not sufficient to > solve all of our security problems, and I readily see that there are > circumstances where the security in the PSTN is considered sufficient. I > claim that's not sips. > > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, November 03, 2006 9:04 AM >> To: Hadriel Kaplan >> Cc: 'Brian Rosen'; 'IETF SIP List' >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >> >> This time Hadriel gave the answer I would have given. >> >> To answer Brian directly, no I don't think the PSTN is secure in the >> sense of TLS. But it does have some security properties that, at least >> on average, are better than what one gets with unsecured sip over the >> internet. Using SIPS sips to reach a GW may provide a useful tool for >> creating an end to end session that is no worse than a pure PSTN >> session. That in itself is worth something. The same is true if it is a >> MESSAGE gateway to SMS. >> >> The SIPS itself doesn't guarantee this. It is only SIPS in combination >> with the UAs and what they do that guarantees that. But everything that >> extends beyond the UAs (including a UA that drives a UI) has such a >> dependency. >> >> (I find the positions in this discussion to be very interesting. I find >> I am aligned with those I have often have had differences with in the >> past, and arguing with those I typically more often agree with. I have >> no idea what that means.) >> >> Paul >> >> Hadriel Kaplan wrote: >>> So far the explanation/argument of sips has been that sips is not a >> synonym >>> for human-to-human security. It does not provide a lock icon. It is >>> nothing more than a mandate that each sip hop use TLS. It is just a uri >>> scheme, which behaves like a require/proxy-require for transport=tls. >> It is >>> nothing more than that. >>> >>> Your proposal is that it become more than a uri scheme for sip; that it >>> become a human-level request for TLS or TLS-level of "secure" (whatever >> that >>> is defined as), regardless of the protocol. That it reaches something >> past >>> the UAS, in some higher plane. Almost like a require that the message >>> headers (and really the body) not leave a cpu. Or maybe a new scheme >> called >>> tls. :) >>> >>> Don't get me wrong - I understand what you mean and why, but SIPS isn't >> it. >>> It would be a significant divergence from 3261 to define a sips uri >> scheme >>> as having such a property, to reach beyond the SIPS UAS, IMO. The uri >> in >>> the sips request is not even the identifier of the SMS receiver. It is >> the >>> identifier of the gateway. If you reached that gateway using TLS, then >> you >>> succeeded. >>> >>> Does any URI or scheme mean more? Http, https, email, ftp, etc. all >>> identify the server/end of the protocol, not something beyond. (an >>> interesting one would be tel - if there was a tels, that is) >>> >>> I think what you're really looking for is a new thing. >>> >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Thursday, November 02, 2006 5:39 PM >>>> To: 'Paul Kyzivat'; 'Elwell, John' >>>> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' >>>> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >>>> >>>> I guess the problem here is whether you consider the PSTN to be secure, >> in >>>> the sense of TLS, expressed in Dean's proposed wording. If you do, >> then >>>> what you propose is consistent. >>>> >>>> Can you give me a use case where sips does something useful when one >> end >>>> is >>>> on the PSTN? >>>> >>>> I don't think anyone believes the PSTN is secure in anything close to >> TLS >>>> level security. I sort of understand the issue of the IETF can only >>>> control >>>> the sip path, and what happens beyond is not in its purview. Using >> that >>>> to >>>> create meaningless mechanisms isn't helpful IMO. >>>> >>>> Let's use the example cited a little while ago: a MESSAGE. You clearly >>>> could, at a gateway, convert that to SMS. Does it make ANY sense to >> call >>>> that secure if it was TLS from UAC to a gateway, and then over a GSM >>>> network >>>> to a handset? Isn't there a substantive difference between that and >> TLS >>>> protected MESSAGE all the way to the handset? What earthly good does >> it >>>> do >>>> to get sips to succeed if the last hop is not secure? I think if the >>>> gateway knows its not the end of the signaling, then it has to fail >> sips >>>> if >>>> it can't maintain TLS. >>>> >>>> Brian >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 11:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2LG-0001xu-Eh; Fri, 03 Nov 2006 11:56:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2LD-0001fv-VQ for sip@ietf.org; Fri, 03 Nov 2006 11:56:27 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2L9-0005Ai-Kh for sip@ietf.org; Fri, 03 Nov 2006 11:56:27 -0500 Received: from [10.69.52.38] (mobile-166-137-176-053.mycingular.net [166.137.176.53]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA3FxX2U003825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Nov 2006 09:59:39 -0600 In-Reply-To: <454B719E.6000507@cisco.com> References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> <706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com> <454B719E.6000507@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 10:55:52 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 3, 2006, at 10:43 AM, Michael Thomas wrote: > > Riddle me this: I assume you have no problem with a SIPS session > terminating > on my host and that I blat out the payload to a terminal window? > What happens > if the terminal window is, oh say, at Times Square via a handy VNC > connection? > > Well, that's your problem. We probably wouldn't document it as a Best Current Practice, however. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 12:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2Rc-00024l-0Z; Fri, 03 Nov 2006 12:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2Ra-00024e-Oe for sip@ietf.org; Fri, 03 Nov 2006 12:03:02 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2RW-0005ba-4r for sip@ietf.org; Fri, 03 Nov 2006 12:03:02 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 09:02:57 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="85111522:sNHT48132657" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3H2v3c021368; Fri, 3 Nov 2006 09:02:57 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA3H2vin025467; Fri, 3 Nov 2006 09:02:57 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn4-499.cisco.com [10.21.81.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA3Gnvic014458; Fri, 3 Nov 2006 08:49:57 -0800 Message-ID: <454B7647.6050809@cisco.com> Date: Fri, 03 Nov 2006 09:03:03 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> <706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com> <454B719E.6000507@cisco.com> <4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> In-Reply-To: <4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=889; t=1162573377; x=1163437377; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DfUTxn6IgjLQQzti8C+nkZkpuBz4=3D; b=cbNvmdo752buyyDfOWRzfL9Am/TirSg5HcRciiANBio1BOjdfgBrguA+qJcTO4MMsfnGInC3 i8TLHmKHk4J9lDY+KlCs7YiT9itF7NC+lpffl4LgqRXKH34HeuRfL8ks; X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 3, 2006, at 10:43 AM, Michael Thomas wrote: > > >> >> Riddle me this: I assume you have no problem with a SIPS session >> terminating >> on my host and that I blat out the payload to a terminal window? >> What happens >> if the terminal window is, oh say, at Times Square via a handy VNC >> connection? >> >> > > Well, that's your problem. We probably wouldn't document it as a Best > Current Practice, however. So the fact that I turned it into a bunch of rectangles and sent it somewhere is enough disqualify it from getting the GoodSIPSkeeping Seal of Approval? What if I mangle it a bit first and make some SIP Haiku before I render it into rectangles? Still not SIPSworthy? Not that we're not talking about a BCP per se: we're talking about whether my host should reject the SIPS message or not. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 12:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2VK-0003na-1L; Fri, 03 Nov 2006 12:06:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2VI-0003nR-3s for sip@ietf.org; Fri, 03 Nov 2006 12:06:52 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2VF-0005uK-Om for sip@ietf.org; Fri, 03 Nov 2006 12:06:52 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 09:06:49 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="754386825:sNHT66845000" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3H6nPa026021; Fri, 3 Nov 2006 09:06:49 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA3H6nAo022520; Fri, 3 Nov 2006 09:06:49 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn4-499.cisco.com [10.21.81.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA3Grn4A014553; Fri, 3 Nov 2006 08:53:49 -0800 Message-ID: <454B772E.7030303@cisco.com> Date: Fri, 03 Nov 2006 09:06:54 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com> <706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com> <454B719E.6000507@cisco.com> <4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> In-Reply-To: <4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=951; t=1162573609; x=1163437609; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3DfUTxn6IgjLQQzti8C+nkZkpuBz4=3D; b=g/iSZsBoS7WdcGBBr5rz/f9Ez8ZJKRMhpkDIpdwDgpsHDq9B/GceZ33Mpoy85OsL3otUhFfI UHkt4aMGByoaZ+eWpo8L3yASxM8DJqF7DiGe9qXLsD/+D5FM7+b6oUtx; X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 3, 2006, at 10:43 AM, Michael Thomas wrote: > > >> >> Riddle me this: I assume you have no problem with a SIPS session >> terminating >> on my host and that I blat out the payload to a terminal window? >> What happens >> if the terminal window is, oh say, at Times Square via a handy VNC >> connection? >> >> > > Well, that's your problem. We probably wouldn't document it as a Best > Current Practice, however. Also: from a Dev standpoint, you're presupposing that the SIP input side of the call leg has any clue whatsoever as to what the output side of the call or whatever else it might be will do with the message. That is think is completely untenable in all but the most fixed function of devices, and even then may be ridiculously difficult. Which is to say: you can specify it in some net.schoolmarm fashion, but that doesn't mean anybody will obey it. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 12:29:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2nj-0004bM-9v; Fri, 03 Nov 2006 12:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2nh-0004Yg-Sx for sip@ietf.org; Fri, 03 Nov 2006 12:25:53 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2nd-0007T7-Ka for sip@ietf.org; Fri, 03 Nov 2006 12:25:53 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA3HPi704206; Fri, 3 Nov 2006 12:25:44 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 11:25:37 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DD9E4D2@zrc2hxm0.corp.nortel.com> In-Reply-To: <047f01c6ff65$c6120f90$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb/UPiaK8M8U0dGShGwa/J+z7bU9AAE/CYgAAIDcIA= From: "Francois Audet" To: "Brian Rosen" , "Paul Kyzivat" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, I'm a bit confused now... Do you think that sips is usable to a PSTN gateway, or not? Or are you saying that it depends what the gateways does with it?=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, November 03, 2006 8:33 AM > To: 'Paul Kyzivat'; 'Hadriel Kaplan' > Cc: 'IETF SIP List' > Subject: RE: [Sip] A sips: trial balloon for you to shoot down >=20 > The proposal Dean made included this text: > >Where TLS is not used, the implementor MUST exercise a high level of=20 > >caution to provide adequate security and MUST preserve operationally=20 > >equivalent protection of message integrity, privacy, and participant=20 > >identity (authentication). >=20 > A PSTN gateway does not do that.=20 >=20 > Again, as has been said, we'll all agree that sips is not=20 > sufficient to solve all of our security problems, and I=20 > readily see that there are circumstances where the security=20 > in the PSTN is considered sufficient. I claim that's not sips. >=20 > Brian >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, November 03, 2006 9:04 AM > > To: Hadriel Kaplan > > Cc: 'Brian Rosen'; 'IETF SIP List' > > Subject: Re: [Sip] A sips: trial balloon for you to shoot down > >=20 > > This time Hadriel gave the answer I would have given. > >=20 > > To answer Brian directly, no I don't think the PSTN is=20 > secure in the=20 > > sense of TLS. But it does have some security properties=20 > that, at least=20 > > on average, are better than what one gets with unsecured=20 > sip over the=20 > > internet. Using SIPS sips to reach a GW may provide a=20 > useful tool for=20 > > creating an end to end session that is no worse than a pure PSTN=20 > > session. That in itself is worth something. The same is=20 > true if it is=20 > > a MESSAGE gateway to SMS. > >=20 > > The SIPS itself doesn't guarantee this. It is only SIPS in=20 > combination=20 > > with the UAs and what they do that guarantees that. But everything=20 > > that extends beyond the UAs (including a UA that drives a=20 > UI) has such=20 > > a dependency. > >=20 > > (I find the positions in this discussion to be very interesting. I=20 > > find I am aligned with those I have often have had=20 > differences with in=20 > > the past, and arguing with those I typically more often=20 > agree with. I=20 > > have no idea what that means.) > >=20 > > Paul > >=20 > > Hadriel Kaplan wrote: > > > So far the explanation/argument of sips has been that=20 > sips is not a > > synonym > > > for human-to-human security. It does not provide a lock=20 > icon. It=20 > > > is nothing more than a mandate that each sip hop use TLS. It is=20 > > > just a uri scheme, which behaves like a=20 > require/proxy-require for transport=3Dtls. > > It is > > > nothing more than that. > > > > > > Your proposal is that it become more than a uri scheme=20 > for sip; that=20 > > > it become a human-level request for TLS or TLS-level of "secure"=20 > > > (whatever > > that > > > is defined as), regardless of the protocol. That it reaches=20 > > > something > > past > > > the UAS, in some higher plane. Almost like a require that the=20 > > > message headers (and really the body) not leave a cpu. =20 > Or maybe a=20 > > > new scheme > > called > > > tls. :) > > > > > > Don't get me wrong - I understand what you mean and why, but SIPS=20 > > > isn't > > it. > > > It would be a significant divergence from 3261 to define=20 > a sips uri > > scheme > > > as having such a property, to reach beyond the SIPS UAS,=20 > IMO. The=20 > > > uri > > in > > > the sips request is not even the identifier of the SMS=20 > receiver. It=20 > > > is > > the > > > identifier of the gateway. If you reached that gateway=20 > using TLS,=20 > > > then > > you > > > succeeded. > > > > > > Does any URI or scheme mean more? Http, https, email,=20 > ftp, etc. all=20 > > > identify the server/end of the protocol, not something=20 > beyond. (an=20 > > > interesting one would be tel - if there was a tels, that is) > > > > > > I think what you're really looking for is a new thing. > > > > > > -hadriel > > > > > > > > >> -----Original Message----- > > >> From: Brian Rosen [mailto:br@brianrosen.net] > > >> Sent: Thursday, November 02, 2006 5:39 PM > > >> To: 'Paul Kyzivat'; 'Elwell, John' > > >> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' > > >> Subject: RE: [Sip] A sips: trial balloon for you to shoot down > > >> > > >> I guess the problem here is whether you consider the PSTN to be=20 > > >> secure, > > in > > >> the sense of TLS, expressed in Dean's proposed wording. =20 > If you do, > > then > > >> what you propose is consistent. > > >> > > >> Can you give me a use case where sips does something useful when=20 > > >> one > > end > > >> is > > >> on the PSTN? > > >> > > >> I don't think anyone believes the PSTN is secure in=20 > anything close=20 > > >> to > > TLS > > >> level security. I sort of understand the issue of the IETF can=20 > > >> only control the sip path, and what happens beyond is not in its=20 > > >> purview. Using > > that > > >> to > > >> create meaningless mechanisms isn't helpful IMO. > > >> > > >> Let's use the example cited a little while ago: a MESSAGE. You=20 > > >> clearly could, at a gateway, convert that to SMS. Does=20 > it make ANY=20 > > >> sense to > > call > > >> that secure if it was TLS from UAC to a gateway, and then over a=20 > > >> GSM network to a handset? Isn't there a substantive difference=20 > > >> between that and > > TLS > > >> protected MESSAGE all the way to the handset? What earthly good=20 > > >> does > > it > > >> do > > >> to get sips to succeed if the last hop is not secure? I=20 > think if=20 > > >> the gateway knows its not the end of the signaling, then=20 > it has to=20 > > >> fail > > sips > > >> if > > >> it can't maintain TLS. > > >> > > >> Brian > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 13:09:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3RD-0001YX-Qw; Fri, 03 Nov 2006 13:06:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3RC-0001YP-Vt for sip@ietf.org; Fri, 03 Nov 2006 13:06:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3R9-0002SW-8k for sip@ietf.org; Fri, 03 Nov 2006 13:06:42 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 10:06:39 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="754407712:sNHT63090308" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3I6cs8031180; Fri, 3 Nov 2006 10:06:38 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA3I6Tj5017679; Fri, 3 Nov 2006 10:06:38 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 13:06:33 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 13:06:33 -0500 Message-ID: <454B8529.2030708@cisco.com> Date: Fri, 03 Nov 2006 13:06:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <047f01c6ff65$c6120f90$640fa8c0@cis.neustar.com> <454B71AE.2070006@cisco.com> In-Reply-To: <454B71AE.2070006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2006 18:06:33.0542 (UTC) FILETIME=[CBB1CE60:01C6FF72] DKIM-Signature: a=rsa-sha1; q=dns; l=7574; t=1162577198; x=1163441198; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=OyttZPKC7Hn3E4vJTfFP9cArUEZdOaScPWus5VooSsj04chP21PSDTqtE5RFrSgnb6ORRQgl d/VqIbJ1UMrtadKD+v08OyfHUWmwMXr/yKX1IJNPKne2Fwy05tD2ntif; Authentication-Results: sj-dkim-3.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to be clear, what I am proposing is that SIPS mean that there is a hop-by-hop TLS connection from UAC to UAS. Period. Nothing more, nothing less. If one of the UAs happens to be a B2BUA, this says nothing about what happens on the other side. If one of the UAs happens to be a PSTN gateway, it says nothing about that either. While this is pretty weak, it has the benefit of being well defined. I don't think we will be getting into disagreements about whether a particular use case complies or not. Will it, by itself, solve any real world security problem? Probably not. But IMO no other plausible definition of sips will do that either. Then we can move on and work on other kinds of security that promise more, possibly using SIPS as a component of the solution. Paul Paul Kyzivat wrote: > > > Brian Rosen wrote: >> The proposal Dean made included this text: >>> Where TLS is not used, the implementor MUST exercise a high level of >>> caution to provide adequate security and MUST preserve operationally >>> equivalent protection of message integrity, privacy, and participant >>> identity (authentication). >> >> A PSTN gateway does not do that. > > And I'm not agreeing with that. I think the UA in this case does what it > does. It may do something special if sips was used, and it may not. > While what it does may be important to the sender at the other end, it > just doesn't have anything to do with SIPS. > > As others have pointed out, this is just like HTTPS. There is nothing in > the specification of HTPPS that requires the HTTPS server to treat the > information it receives securely. > > Based on your criteria, if a server receives a MESSAGE over SIPS, what > may it do with it, and what may it not do with it? Can it store the > message on a file server? Does it matter what the security of the file > server is? How is storing it on an insecure file server any better than > sending it via SMS? > > Paul > >> Again, as has been said, we'll all agree that sips is not sufficient to >> solve all of our security problems, and I readily see that there are >> circumstances where the security in the PSTN is considered sufficient. I >> claim that's not sips. >> >> Brian >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Friday, November 03, 2006 9:04 AM >>> To: Hadriel Kaplan >>> Cc: 'Brian Rosen'; 'IETF SIP List' >>> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >>> >>> This time Hadriel gave the answer I would have given. >>> >>> To answer Brian directly, no I don't think the PSTN is secure in the >>> sense of TLS. But it does have some security properties that, at least >>> on average, are better than what one gets with unsecured sip over the >>> internet. Using SIPS sips to reach a GW may provide a useful tool for >>> creating an end to end session that is no worse than a pure PSTN >>> session. That in itself is worth something. The same is true if it is a >>> MESSAGE gateway to SMS. >>> >>> The SIPS itself doesn't guarantee this. It is only SIPS in combination >>> with the UAs and what they do that guarantees that. But everything that >>> extends beyond the UAs (including a UA that drives a UI) has such a >>> dependency. >>> >>> (I find the positions in this discussion to be very interesting. I find >>> I am aligned with those I have often have had differences with in the >>> past, and arguing with those I typically more often agree with. I have >>> no idea what that means.) >>> >>> Paul >>> >>> Hadriel Kaplan wrote: >>>> So far the explanation/argument of sips has been that sips is not a >>> synonym >>>> for human-to-human security. It does not provide a lock icon. It is >>>> nothing more than a mandate that each sip hop use TLS. It is just a >>>> uri >>>> scheme, which behaves like a require/proxy-require for transport=tls. >>> It is >>>> nothing more than that. >>>> >>>> Your proposal is that it become more than a uri scheme for sip; that it >>>> become a human-level request for TLS or TLS-level of "secure" (whatever >>> that >>>> is defined as), regardless of the protocol. That it reaches something >>> past >>>> the UAS, in some higher plane. Almost like a require that the message >>>> headers (and really the body) not leave a cpu. Or maybe a new scheme >>> called >>>> tls. :) >>>> >>>> Don't get me wrong - I understand what you mean and why, but SIPS isn't >>> it. >>>> It would be a significant divergence from 3261 to define a sips uri >>> scheme >>>> as having such a property, to reach beyond the SIPS UAS, IMO. The uri >>> in >>>> the sips request is not even the identifier of the SMS receiver. It is >>> the >>>> identifier of the gateway. If you reached that gateway using TLS, then >>> you >>>> succeeded. >>>> >>>> Does any URI or scheme mean more? Http, https, email, ftp, etc. all >>>> identify the server/end of the protocol, not something beyond. (an >>>> interesting one would be tel - if there was a tels, that is) >>>> >>>> I think what you're really looking for is a new thing. >>>> >>>> -hadriel >>>> >>>> >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Thursday, November 02, 2006 5:39 PM >>>>> To: 'Paul Kyzivat'; 'Elwell, John' >>>>> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' >>>>> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >>>>> >>>>> I guess the problem here is whether you consider the PSTN to be >>>>> secure, >>> in >>>>> the sense of TLS, expressed in Dean's proposed wording. If you do, >>> then >>>>> what you propose is consistent. >>>>> >>>>> Can you give me a use case where sips does something useful when one >>> end >>>>> is >>>>> on the PSTN? >>>>> >>>>> I don't think anyone believes the PSTN is secure in anything close to >>> TLS >>>>> level security. I sort of understand the issue of the IETF can only >>>>> control >>>>> the sip path, and what happens beyond is not in its purview. Using >>> that >>>>> to >>>>> create meaningless mechanisms isn't helpful IMO. >>>>> >>>>> Let's use the example cited a little while ago: a MESSAGE. You >>>>> clearly >>>>> could, at a gateway, convert that to SMS. Does it make ANY sense to >>> call >>>>> that secure if it was TLS from UAC to a gateway, and then over a GSM >>>>> network >>>>> to a handset? Isn't there a substantive difference between that and >>> TLS >>>>> protected MESSAGE all the way to the handset? What earthly good does >>> it >>>>> do >>>>> to get sips to succeed if the last hop is not secure? I think if the >>>>> gateway knows its not the end of the signaling, then it has to fail >>> sips >>>>> if >>>>> it can't maintain TLS. >>>>> >>>>> Brian >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 13:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3eo-0006gB-SI; Fri, 03 Nov 2006 13:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3en-0006g5-P5 for sip@ietf.org; Fri, 03 Nov 2006 13:20:45 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3el-0003ww-Dc for sip@ietf.org; Fri, 03 Nov 2006 13:20:45 -0500 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.10) id A864054C; Fri, 03 Nov 2006 13:20:20 -0500 Message-ID: <003c01c6ff74$b86ae420$800101df@acmepacket.com> From: "Bob Penfield" To: "Michael Thomas" , "Dean Willis" References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com><706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com><454B719E.6000507@cisco.com><4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> <454B772E.7030303@cisco.com> Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 13:20:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'IETF SIP List' , 'Paul Kyzivat' , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What if we turn this around? The PSTN circuit switched world has physical security. Its users have some assurance that the "bits" of their phone call are delivered intact and only those with access to and control of the switching equipment could see or muck with those bits. In the packet world, we must use TLS to provide the same assurance because things in the clear can be seen and mucked by anybody with a computer. With TLS, only those with access to or control of the intermediaries (proxies, B2BUA, SBCs, etc) can see or muck with the signaling "bits". We have the a similar sort of transitive trust, although in the wide open Internet we may have not have the pre-established relationships between providers as exists in the PSTN. The requirement for sips is at a minimum is to provide that level of security. Its not to equal a military secure phone. That's the next level of security that needs to be worked on. Therefore, I would say, that a PSTN gateway injecting a call into the sip network MUST use sips to at least equal the level of security provided by the PSTN. If we want a level of security that would require the PSTN to provide the military secure phone, that's something more than sips. I guess that would make sips equivalent to Dean's idea of BCP SIPoverTLS. But I think that is what sips is today. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Michael Thomas" To: "Dean Willis" Cc: "'IETF SIP List'" ; "'Paul Kyzivat'" ; "'Elwell, John'" ; "'Francois Audet'" Sent: Friday, November 03, 2006 12:06 PM Subject: Re: [Sip] A sips: trial balloon for you to shoot down > Dean Willis wrote: > >> >> On Nov 3, 2006, at 10:43 AM, Michael Thomas wrote: >> >> >>> >>> Riddle me this: I assume you have no problem with a SIPS session >>> terminating >>> on my host and that I blat out the payload to a terminal window? What >>> happens >>> if the terminal window is, oh say, at Times Square via a handy VNC >>> connection? >>> >>> >> >> Well, that's your problem. We probably wouldn't document it as a Best >> Current Practice, however. > > Also: from a Dev standpoint, you're presupposing that the SIP input side > of the > call leg has any clue whatsoever as to what the output side of the call or > whatever > else it might be will do with the message. That is think is completely > untenable in > all but the most fixed function of devices, and even then may be > ridiculously > difficult. Which is to say: you can specify it in some net.schoolmarm > fashion, but > that doesn't mean anybody will obey it. > > Mike > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 13:42:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3x3-0007Xa-63; Fri, 03 Nov 2006 13:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3x1-0007Rf-Ku for sip@ietf.org; Fri, 03 Nov 2006 13:39:35 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3wy-000654-4k for sip@ietf.org; Fri, 03 Nov 2006 13:39:35 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA3IdSS11564; Fri, 3 Nov 2006 13:39:28 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 12:39:27 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DD9E62A@zrc2hxm0.corp.nortel.com> In-Reply-To: <454B8529.2030708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb/c453qbSZTNlUREmsq4K7/f5TIgAAx9Lg From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, if I understand you correctly, you favor allowing SIPS to PSTN=20 gateway, regardless of what it does after, right? > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, November 03, 2006 10:07 AM > To: Paul Kyzivat > Cc: 'IETF SIP List' > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 > Just to be clear, what I am proposing is that SIPS mean that=20 > there is a hop-by-hop TLS connection from UAC to UAS. Period.=20 > Nothing more, nothing less. >=20 > If one of the UAs happens to be a B2BUA, this says nothing=20 > about what happens on the other side. If one of the UAs=20 > happens to be a PSTN gateway, it says nothing about that either. >=20 > While this is pretty weak, it has the benefit of being well=20 > defined. I don't think we will be getting into disagreements=20 > about whether a particular use case complies or not. >=20 > Will it, by itself, solve any real world security problem?=20 > Probably not.=20 > But IMO no other plausible definition of sips will do that either. >=20 > Then we can move on and work on other kinds of security that=20 > promise more, possibly using SIPS as a component of the solution. >=20 > Paul >=20 > Paul Kyzivat wrote: > >=20 > >=20 > > Brian Rosen wrote: > >> The proposal Dean made included this text: > >>> Where TLS is not used, the implementor MUST exercise a=20 > high level of=20 > >>> caution to provide adequate security and MUST preserve=20 > operationally=20 > >>> equivalent protection of message integrity, privacy, and=20 > participant=20 > >>> identity (authentication). > >> > >> A PSTN gateway does not do that.=20 > >=20 > > And I'm not agreeing with that. I think the UA in this case=20 > does what=20 > > it does. It may do something special if sips was used, and=20 > it may not. > > While what it does may be important to the sender at the=20 > other end, it=20 > > just doesn't have anything to do with SIPS. > >=20 > > As others have pointed out, this is just like HTTPS. There=20 > is nothing=20 > > in the specification of HTPPS that requires the HTTPS=20 > server to treat=20 > > the information it receives securely. > >=20 > > Based on your criteria, if a server receives a MESSAGE over=20 > SIPS, what=20 > > may it do with it, and what may it not do with it? Can it store the=20 > > message on a file server? Does it matter what the security=20 > of the file=20 > > server is? How is storing it on an insecure file server any better=20 > > than sending it via SMS? > >=20 > > Paul > >=20 > >> Again, as has been said, we'll all agree that sips is not=20 > sufficient=20 > >> to solve all of our security problems, and I readily see=20 > that there=20 > >> are circumstances where the security in the PSTN is considered=20 > >> sufficient. I claim that's not sips. > >> > >> Brian > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: Friday, November 03, 2006 9:04 AM > >>> To: Hadriel Kaplan > >>> Cc: 'Brian Rosen'; 'IETF SIP List' > >>> Subject: Re: [Sip] A sips: trial balloon for you to shoot down > >>> > >>> This time Hadriel gave the answer I would have given. > >>> > >>> To answer Brian directly, no I don't think the PSTN is=20 > secure in the=20 > >>> sense of TLS. But it does have some security properties that, at=20 > >>> least on average, are better than what one gets with=20 > unsecured sip=20 > >>> over the internet. Using SIPS sips to reach a GW may provide a=20 > >>> useful tool for creating an end to end session that is no=20 > worse than=20 > >>> a pure PSTN session. That in itself is worth something.=20 > The same is=20 > >>> true if it is a MESSAGE gateway to SMS. > >>> > >>> The SIPS itself doesn't guarantee this. It is only SIPS in=20 > >>> combination with the UAs and what they do that guarantees=20 > that. But=20 > >>> everything that extends beyond the UAs (including a UA=20 > that drives a=20 > >>> UI) has such a dependency. > >>> > >>> (I find the positions in this discussion to be very=20 > interesting. I=20 > >>> find I am aligned with those I have often have had=20 > differences with=20 > >>> in the past, and arguing with those I typically more often agree=20 > >>> with. I have no idea what that means.) > >>> > >>> Paul > >>> > >>> Hadriel Kaplan wrote: > >>>> So far the explanation/argument of sips has been that=20 > sips is not a > >>> synonym > >>>> for human-to-human security. It does not provide a lock=20 > icon. It=20 > >>>> is nothing more than a mandate that each sip hop use TLS. It is=20 > >>>> just a uri scheme, which behaves like a=20 > require/proxy-require for=20 > >>>> transport=3Dtls. > >>> It is > >>>> nothing more than that. > >>>> > >>>> Your proposal is that it become more than a uri scheme for sip;=20 > >>>> that it become a human-level request for TLS or TLS-level of=20 > >>>> "secure" (whatever > >>> that > >>>> is defined as), regardless of the protocol. That it reaches=20 > >>>> something > >>> past > >>>> the UAS, in some higher plane. Almost like a require that the=20 > >>>> message headers (and really the body) not leave a cpu. =20 > Or maybe a=20 > >>>> new scheme > >>> called > >>>> tls. :) > >>>> > >>>> Don't get me wrong - I understand what you mean and why,=20 > but SIPS=20 > >>>> isn't > >>> it. > >>>> It would be a significant divergence from 3261 to define=20 > a sips uri > >>> scheme > >>>> as having such a property, to reach beyond the SIPS UAS,=20 > IMO. The=20 > >>>> uri > >>> in > >>>> the sips request is not even the identifier of the SMS=20 > receiver. =20 > >>>> It is > >>> the > >>>> identifier of the gateway. If you reached that gateway=20 > using TLS,=20 > >>>> then > >>> you > >>>> succeeded. > >>>> > >>>> Does any URI or scheme mean more? Http, https, email, ftp, etc.=20 > >>>> all identify the server/end of the protocol, not=20 > something beyond.=20 > >>>> (an interesting one would be tel - if there was a tels, that is) > >>>> > >>>> I think what you're really looking for is a new thing. > >>>> > >>>> -hadriel > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>>> Sent: Thursday, November 02, 2006 5:39 PM > >>>>> To: 'Paul Kyzivat'; 'Elwell, John' > >>>>> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' > >>>>> Subject: RE: [Sip] A sips: trial balloon for you to shoot down > >>>>> > >>>>> I guess the problem here is whether you consider the PSTN to be=20 > >>>>> secure, > >>> in > >>>>> the sense of TLS, expressed in Dean's proposed wording. If you=20 > >>>>> do, > >>> then > >>>>> what you propose is consistent. > >>>>> > >>>>> Can you give me a use case where sips does something=20 > useful when=20 > >>>>> one > >>> end > >>>>> is > >>>>> on the PSTN? > >>>>> > >>>>> I don't think anyone believes the PSTN is secure in=20 > anything close=20 > >>>>> to > >>> TLS > >>>>> level security. I sort of understand the issue of the IETF can=20 > >>>>> only control the sip path, and what happens beyond is=20 > not in its=20 > >>>>> purview. Using > >>> that > >>>>> to > >>>>> create meaningless mechanisms isn't helpful IMO. > >>>>> > >>>>> Let's use the example cited a little while ago: a MESSAGE. You=20 > >>>>> clearly could, at a gateway, convert that to SMS. Does it make=20 > >>>>> ANY sense to > >>> call > >>>>> that secure if it was TLS from UAC to a gateway, and=20 > then over a=20 > >>>>> GSM network to a handset? Isn't there a substantive difference=20 > >>>>> between that and > >>> TLS > >>>>> protected MESSAGE all the way to the handset? What=20 > earthly good=20 > >>>>> does > >>> it > >>>>> do > >>>>> to get sips to succeed if the last hop is not secure? =20 > I think if=20 > >>>>> the gateway knows its not the end of the signaling,=20 > then it has to=20 > >>>>> fail > >>> sips > >>>>> if > >>>>> it can't maintain TLS. > >>>>> > >>>>> Brian > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>>> > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 13:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3yT-00014I-3m; Fri, 03 Nov 2006 13:41:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3yS-00014D-K2 for sip@ietf.org; Fri, 03 Nov 2006 13:41:04 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3yQ-0006BP-72 for sip@ietf.org; Fri, 03 Nov 2006 13:41:04 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA3IY8R03516; Fri, 3 Nov 2006 13:34:08 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 12:40:56 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DD9E634@zrc2hxm0.corp.nortel.com> In-Reply-To: <003c01c6ff74$b86ae420$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb/dMFM1C0BB8MYREOxl82aNHm2HQAAqovA From: "Francois Audet" To: "Bob Penfield" , "Michael Thomas" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think this is doable. It just means all existing SIP implementations in the world would be uncompliant. It could be a RECOMMENDED strenght however. But even that I think is controversial.=20 > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 > Sent: Friday, November 03, 2006 10:20 AM > To: Michael Thomas; Dean Willis > Cc: 'IETF SIP List'; 'Paul Kyzivat'; 'Elwell, John'; Audet,=20 > Francois (SC100:3055) > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 > What if we turn this around? >=20 > The PSTN circuit switched world has physical security. Its=20 > users have some assurance that the "bits" of their phone call=20 > are delivered intact and only those with access to and=20 > control of the switching equipment could see or muck with=20 > those bits. In the packet world, we must use TLS to provide=20 > the same assurance because things in the clear can be seen=20 > and mucked by anybody with a computer. With TLS, only those=20 > with access to or control of the intermediaries (proxies,=20 > B2BUA, SBCs, etc) can see or muck with the signaling "bits".=20 > We have the a similar sort of transitive trust, although in=20 > the wide open Internet we may have not have the=20 > pre-established relationships between providers as exists in the PSTN. >=20 > The requirement for sips is at a minimum is to provide that=20 > level of security. Its not to equal a military secure phone.=20 > That's the next level of security that needs to be worked on. >=20 > Therefore, I would say, that a PSTN gateway injecting a call=20 > into the sip network MUST use sips to at least equal the=20 > level of security provided by the PSTN. >=20 > If we want a level of security that would require the PSTN to=20 > provide the military secure phone, that's something more than sips. >=20 > I guess that would make sips equivalent to Dean's idea of BCP=20 > SIPoverTLS.=20 > But I think that is what sips is today. >=20 > cheers, > (-:bob >=20 > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > bpenfield@acmepacket.com >=20 >=20 >=20 > ----- Original Message ----- > From: "Michael Thomas" > To: "Dean Willis" > Cc: "'IETF SIP List'" ; "'Paul Kyzivat'"=20 > ; "'Elwell, John'"=20 > ; "'Francois Audet'"=20 > > Sent: Friday, November 03, 2006 12:06 PM > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 > > Dean Willis wrote: > > > >> > >> On Nov 3, 2006, at 10:43 AM, Michael Thomas wrote: > >> > >> > >>> > >>> Riddle me this: I assume you have no problem with a SIPS session=20 > >>> terminating on my host and that I blat out the payload to=20 > a terminal=20 > >>> window? What happens if the terminal window is, oh say, at Times=20 > >>> Square via a handy VNC connection? > >>> > >>> > >> > >> Well, that's your problem. We probably wouldn't document=20 > it as a Best=20 > >> Current Practice, however. > > > > Also: from a Dev standpoint, you're presupposing that the SIP input=20 > > side of the call leg has any clue whatsoever as to what the output=20 > > side of the call or whatever else it might be will do with the=20 > > message. That is think is completely untenable in all but the most=20 > > fixed function of devices, and even then may be ridiculously=20 > > difficult. Which is to say: you can specify it in some=20 > net.schoolmarm=20 > > fashion, but that doesn't mean anybody will obey it. > > > > Mike > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 14:03:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4IG-0001SA-8v; Fri, 03 Nov 2006 14:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4IE-0001Ca-7d for sip@ietf.org; Fri, 03 Nov 2006 14:01:30 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4IA-0000oz-SB for sip@ietf.org; Fri, 03 Nov 2006 14:01:30 -0500 Received: (from apache@localhost) by figas.ekabal.com (8.11.6/8.11.6) id kA3J14h09979; Fri, 3 Nov 2006 11:01:04 -0800 From: Rohan Mahy X-Authentication-Warning: figas.ekabal.com: apache set sender to rohan@localhost using -f Received: from 12.151.41.2 (SquirrelMail authenticated user rohan); by figas.ekabal.com with HTTP; Fri, 3 Nov 2006 11:01:03 -0800 (PST) Message-ID: <24748.12.151.41.2.1162580463.squirrel@12.151.41.2> In-Reply-To: <5D44628035C1F54BB415BBD135F5BECF5F4F42@esealmw113.eemea.ericsson.se> References: <19980.12.151.41.2.1162504104.squirrel@12.151.41.2> <5D44628035C1F54BB415BBD135F5BECF5F4F42@esealmw113.eemea.ericsson.se> Date: Fri, 3 Nov 2006 11:01:03 -0800 (PST) To: "Christer Holmberg \(JO/LMF\)" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List , Rohan Mahy Subject: [Sip] RE: Outbound-05: Indication of number of flows to register X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, I sent out an email to the list with the subject "Outbound issues: slide 7". This topic was also discussed in the meeting and on the mailing list before the meeting. I received many, many responses supportive of leaving this functionality out. I have heard only one request for its inclusion (from you). thanks, -rohan > Hi, > >>We have explicit consensus not to include this functionality in > outbound. > > We do? When was that consensus reached? At least not as part of the "Re: > [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER" mail thread, as > far as I am aware. > > And, no matter if we have that indicator or not, which error code shall > the registrar use if a user has reached the maximum number of flows, and > the registrar does not accept more flows? > > Regards, > > Christer > > > > >> > Hi, >> > >> > One issue that has been discussed for outbound is to allow >> the network >> > to indicate to the UA how many flows are accepted, and/or how many >> > flows the user is recommended to register. This value could e.g. be >> > provided by the registrar. Otherwise, if the maximum number >> of flows >> > is reached, registration requests would have to be >> rejected, which is not good. >> > >> > So, my proposal is still that it should be added to outbound. >> > >> > Regards, >> > >> > Christer >> > >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 14:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4U0-0004z0-WB; Fri, 03 Nov 2006 14:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4Tz-0004yb-Ac for sip@ietf.org; Fri, 03 Nov 2006 14:13:39 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4Tq-0002Xp-Nz for sip@ietf.org; Fri, 03 Nov 2006 14:13:39 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 973A85BF; Fri, 3 Nov 2006 20:13:09 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 20:13:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Nov 2006 20:13:01 +0100 Message-ID: <7374777208BDC7449D5620EF94232567143140@esealmw113.eemea.ericsson.se> In-Reply-To: <24748.12.151.41.2.1162580463.squirrel@12.151.41.2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: Indication of number of flows to register Thread-Index: Acb/em9dRoajPBauTHSoIArpuilrSQAAJxbg From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 03 Nov 2006 19:13:09.0596 (UTC) FILETIME=[198741C0:01C6FF7C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IETF SIP List Subject: [Sip] RE: Outbound-05: Indication of number of flows to register X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, I thought that slide 7 was about the discovery of outbound-proxy-set, but that is really not the same thing. What I am talking about is a value which is returned in the registration response, once you have discovered your outbound proxies and sent your first registrations.=20 I didn't even find the max-flow issue in the slides. And, if I remember at least Erikki Koivusalo indicated that this kind of value would be useful. I haven't really seen any objection to it on the mailing list, but I may of course have missed that. Regards, Christer =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: 3. marraskuuta 2006 21:01 > To: Christer Holmberg (JO/LMF) > Cc: Rohan Mahy; IETF SIP List > Subject: RE: Outbound-05: Indication of number of flows to register >=20 > Hi Christer, >=20 > I sent out an email to the list with the subject "Outbound=20 > issues: slide 7". This topic was also discussed in the=20 > meeting and on the mailing list before the meeting. >=20 > I received many, many responses supportive of leaving this=20 > functionality out. I have heard only one request for its=20 > inclusion (from you). >=20 > thanks, > -rohan >=20 >=20 >=20 > > Hi, > > > >>We have explicit consensus not to include this functionality in > > outbound. > > > > We do? When was that consensus reached? At least not as=20 > part of the "Re: > > [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER"=20 > mail thread,=20 > > as far as I am aware. > > > > And, no matter if we have that indicator or not, which error code=20 > > shall the registrar use if a user has reached the maximum number of=20 > > flows, and the registrar does not accept more flows? > > > > Regards, > > > > Christer > > > > > > > > > >> > Hi, > >> > > >> > One issue that has been discussed for outbound is to allow > >> the network > >> > to indicate to the UA how many flows are accepted,=20 > and/or how many=20 > >> > flows the user is recommended to register. This value=20 > could e.g. be=20 > >> > provided by the registrar. Otherwise, if the maximum number > >> of flows > >> > is reached, registration requests would have to be > >> rejected, which is not good. > >> > > >> > So, my proposal is still that it should be added to outbound. > >> > > >> > Regards, > >> > > >> > Christer > >> > > >> > >> > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 14:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4eC-000889-8T; Fri, 03 Nov 2006 14:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4eA-00087x-DZ for sip@ietf.org; Fri, 03 Nov 2006 14:24:10 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4e5-0004Sv-Lt for sip@ietf.org; Fri, 03 Nov 2006 14:24:10 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2006 11:24:03 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADQmS0WrR7MVh2dsb2JhbACMSgEBAQgOKg X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="349927735:sNHT45545830" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3JO22w009693; Fri, 3 Nov 2006 11:24:02 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA3JNnOl011748; Fri, 3 Nov 2006 11:24:01 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 14:24:01 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 14:24:00 -0500 Message-ID: <454B9750.1060104@cisco.com> Date: Fri, 03 Nov 2006 14:24:00 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] A sips: trial balloon for you to shoot down References: <1ECE0EB50388174790F9694F77522CCF0DD9E62A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DD9E62A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2006 19:24:00.0940 (UTC) FILETIME=[9DC276C0:01C6FF7D] DKIM-Signature: a=rsa-sha1; q=dns; l=8996; t=1162581842; x=1163445842; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down; X=v=3Dcisco.com=3B=20h=3D3poIK7GczsDA4+ftKL9VWfUhJ8I=3D; b=d75pd0ETHmDeZz+FUcTKDTpw2TJUpkJU6NjNdxdQ7LIJUXm5IL8M7gPhWyetG6yGLNbTbyiI Hw8w9OqYyMvuNcYQg6MhN/yUOGBCvOwi+wCqLd1RHcZZBk3Eez9KfSc7; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > So, if I understand you correctly, you favor allowing SIPS to PSTN > gateway, regardless of what it does after, right? Yup. >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, November 03, 2006 10:07 AM >> To: Paul Kyzivat >> Cc: 'IETF SIP List' >> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >> >> Just to be clear, what I am proposing is that SIPS mean that >> there is a hop-by-hop TLS connection from UAC to UAS. Period. >> Nothing more, nothing less. >> >> If one of the UAs happens to be a B2BUA, this says nothing >> about what happens on the other side. If one of the UAs >> happens to be a PSTN gateway, it says nothing about that either. >> >> While this is pretty weak, it has the benefit of being well >> defined. I don't think we will be getting into disagreements >> about whether a particular use case complies or not. >> >> Will it, by itself, solve any real world security problem? >> Probably not. >> But IMO no other plausible definition of sips will do that either. >> >> Then we can move on and work on other kinds of security that >> promise more, possibly using SIPS as a component of the solution. >> >> Paul >> >> Paul Kyzivat wrote: >>> >>> Brian Rosen wrote: >>>> The proposal Dean made included this text: >>>>> Where TLS is not used, the implementor MUST exercise a >> high level of >>>>> caution to provide adequate security and MUST preserve >> operationally >>>>> equivalent protection of message integrity, privacy, and >> participant >>>>> identity (authentication). >>>> A PSTN gateway does not do that. >>> And I'm not agreeing with that. I think the UA in this case >> does what >>> it does. It may do something special if sips was used, and >> it may not. >>> While what it does may be important to the sender at the >> other end, it >>> just doesn't have anything to do with SIPS. >>> >>> As others have pointed out, this is just like HTTPS. There >> is nothing >>> in the specification of HTPPS that requires the HTTPS >> server to treat >>> the information it receives securely. >>> >>> Based on your criteria, if a server receives a MESSAGE over >> SIPS, what >>> may it do with it, and what may it not do with it? Can it store the >>> message on a file server? Does it matter what the security >> of the file >>> server is? How is storing it on an insecure file server any better >>> than sending it via SMS? >>> >>> Paul >>> >>>> Again, as has been said, we'll all agree that sips is not >> sufficient >>>> to solve all of our security problems, and I readily see >> that there >>>> are circumstances where the security in the PSTN is considered >>>> sufficient. I claim that's not sips. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Friday, November 03, 2006 9:04 AM >>>>> To: Hadriel Kaplan >>>>> Cc: 'Brian Rosen'; 'IETF SIP List' >>>>> Subject: Re: [Sip] A sips: trial balloon for you to shoot down >>>>> >>>>> This time Hadriel gave the answer I would have given. >>>>> >>>>> To answer Brian directly, no I don't think the PSTN is >> secure in the >>>>> sense of TLS. But it does have some security properties that, at >>>>> least on average, are better than what one gets with >> unsecured sip >>>>> over the internet. Using SIPS sips to reach a GW may provide a >>>>> useful tool for creating an end to end session that is no >> worse than >>>>> a pure PSTN session. That in itself is worth something. >> The same is >>>>> true if it is a MESSAGE gateway to SMS. >>>>> >>>>> The SIPS itself doesn't guarantee this. It is only SIPS in >>>>> combination with the UAs and what they do that guarantees >> that. But >>>>> everything that extends beyond the UAs (including a UA >> that drives a >>>>> UI) has such a dependency. >>>>> >>>>> (I find the positions in this discussion to be very >> interesting. I >>>>> find I am aligned with those I have often have had >> differences with >>>>> in the past, and arguing with those I typically more often agree >>>>> with. I have no idea what that means.) >>>>> >>>>> Paul >>>>> >>>>> Hadriel Kaplan wrote: >>>>>> So far the explanation/argument of sips has been that >> sips is not a >>>>> synonym >>>>>> for human-to-human security. It does not provide a lock >> icon. It >>>>>> is nothing more than a mandate that each sip hop use TLS. It is >>>>>> just a uri scheme, which behaves like a >> require/proxy-require for >>>>>> transport=tls. >>>>> It is >>>>>> nothing more than that. >>>>>> >>>>>> Your proposal is that it become more than a uri scheme for sip; >>>>>> that it become a human-level request for TLS or TLS-level of >>>>>> "secure" (whatever >>>>> that >>>>>> is defined as), regardless of the protocol. That it reaches >>>>>> something >>>>> past >>>>>> the UAS, in some higher plane. Almost like a require that the >>>>>> message headers (and really the body) not leave a cpu. >> Or maybe a >>>>>> new scheme >>>>> called >>>>>> tls. :) >>>>>> >>>>>> Don't get me wrong - I understand what you mean and why, >> but SIPS >>>>>> isn't >>>>> it. >>>>>> It would be a significant divergence from 3261 to define >> a sips uri >>>>> scheme >>>>>> as having such a property, to reach beyond the SIPS UAS, >> IMO. The >>>>>> uri >>>>> in >>>>>> the sips request is not even the identifier of the SMS >> receiver. >>>>>> It is >>>>> the >>>>>> identifier of the gateway. If you reached that gateway >> using TLS, >>>>>> then >>>>> you >>>>>> succeeded. >>>>>> >>>>>> Does any URI or scheme mean more? Http, https, email, ftp, etc. >>>>>> all identify the server/end of the protocol, not >> something beyond. >>>>>> (an interesting one would be tel - if there was a tels, that is) >>>>>> >>>>>> I think what you're really looking for is a new thing. >>>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>> Sent: Thursday, November 02, 2006 5:39 PM >>>>>>> To: 'Paul Kyzivat'; 'Elwell, John' >>>>>>> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis' >>>>>>> Subject: RE: [Sip] A sips: trial balloon for you to shoot down >>>>>>> >>>>>>> I guess the problem here is whether you consider the PSTN to be >>>>>>> secure, >>>>> in >>>>>>> the sense of TLS, expressed in Dean's proposed wording. If you >>>>>>> do, >>>>> then >>>>>>> what you propose is consistent. >>>>>>> >>>>>>> Can you give me a use case where sips does something >> useful when >>>>>>> one >>>>> end >>>>>>> is >>>>>>> on the PSTN? >>>>>>> >>>>>>> I don't think anyone believes the PSTN is secure in >> anything close >>>>>>> to >>>>> TLS >>>>>>> level security. I sort of understand the issue of the IETF can >>>>>>> only control the sip path, and what happens beyond is >> not in its >>>>>>> purview. Using >>>>> that >>>>>>> to >>>>>>> create meaningless mechanisms isn't helpful IMO. >>>>>>> >>>>>>> Let's use the example cited a little while ago: a MESSAGE. You >>>>>>> clearly could, at a gateway, convert that to SMS. Does it make >>>>>>> ANY sense to >>>>> call >>>>>>> that secure if it was TLS from UAC to a gateway, and >> then over a >>>>>>> GSM network to a handset? Isn't there a substantive difference >>>>>>> between that and >>>>> TLS >>>>>>> protected MESSAGE all the way to the handset? What >> earthly good >>>>>>> does >>>>> it >>>>>>> do >>>>>>> to get sips to succeed if the last hop is not secure? >> I think if >>>>>>> the gateway knows its not the end of the signaling, >> then it has to >>>>>>> fail >>>>> sips >>>>>>> if >>>>>>> it can't maintain TLS. >>>>>>> >>>>>>> Brian >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 14:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4zq-0002VP-Jp; Fri, 03 Nov 2006 14:46:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4zp-0002Ui-DH for sip@ietf.org; Fri, 03 Nov 2006 14:46:33 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4zn-0007Bh-5f for sip@ietf.org; Fri, 03 Nov 2006 14:46:33 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gg4zY-0005NG-TN; Fri, 03 Nov 2006 13:46:23 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 14:46:20 -0500 Message-ID: <04e701c6ff80$c1f6c6b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb/cs0ocTFPUeFATYq6envQ+zXcLgADTyaw In-Reply-To: <454B8529.2030708@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > While this is pretty weak, it has the benefit of being well defined. I > don't think we will be getting into disagreements about whether a > particular use case complies or not. > > Will it, by itself, solve any real world security problem? Probably not. > But IMO no other plausible definition of sips will do that either. Okay, so what you are REALLY saying is deprecate sips. You admit that what you want to do is not useful. > Then we can move on and work on other kinds of security that promise > more, possibly using SIPS as a component of the solution. Right. Come back in a year or so, and we'll have some drafts to look at. Same old, same old. We've been saying that for 4 or 5 YEARS. So far, nothing which we think is useful has been proposed. Everything gets shut down, mostly because it doesn't solve someone's problem they think HAS to be solved by the proposed mechanism. I think we can get something useful out of sips. I think Dean did a decent job of defining what that is. I think it's not perfect. It doesn't meet everyone's needs. It will have judgment calls to be made. But I think it will be quite useful. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 17:42:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7g7-00013U-0s; Fri, 03 Nov 2006 17:38:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7g4-00012Y-So for sip@ietf.org; Fri, 03 Nov 2006 17:38:20 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg7g3-0000nm-KM for sip@ietf.org; Fri, 03 Nov 2006 17:38:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA3MVCR21304; Fri, 3 Nov 2006 17:31:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A sips: trial balloon for you to shoot down Date: Fri, 3 Nov 2006 16:38:01 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C10F@zrc2hxm2.corp.nortel.com> In-Reply-To: <454B8529.2030708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb/cyrgtmXyCkTWRkO+f05Rch0wGwAJLVGw From: "Samir Srivastava" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In-line. Thx Samir =20 >=20 > Will it, by itself, solve any real world security problem? Probably not. > But IMO no other plausible definition of sips will do that either. Looks like you are agreeing to _deprecate_ sips. Thx. >=20 > Then we can move on and work on other kinds of security that promise > more, possibly using SIPS as a component of the solution. This is what I want to avoid, which I said earlier too. The strength of the chain is the strength of the weakest link. We will have one more beast within SIP itself to inter-work. >=20 > Paul =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 17:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7jw-0003ck-Ed; Fri, 03 Nov 2006 17:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7ju-0003cf-KP for sip@ietf.org; Fri, 03 Nov 2006 17:42:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg7jt-0001yT-54 for sip@ietf.org; Fri, 03 Nov 2006 17:42:18 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2006 14:42:16 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="339299530:sNHT50828020" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3MgGE1023992; Fri, 3 Nov 2006 14:42:16 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA3MfmOV012615; Fri, 3 Nov 2006 14:41:57 -0800 (PST) From: "Dan Wing" To: "'Dean Willis'" , "'Aki Niemi'" Subject: RE: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Fri, 3 Nov 2006 14:41:40 -0800 Message-ID: <09bb01c6ff99$4dda5030$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb+sPLtC4ZStOzmQGSD3yEqBtwtZQA5oyZw In-Reply-To: <82865BE3-7273-42E6-AD33-EA4D17A13B9F@softarmor.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1829; t=1162593736; x=1163457736; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20SIP=20as=20an=20alternative=20to=20IKE?, =20was=3A=20Re=3A=20[Sip ]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DZ900UAtsznM7B7dtVED9pHCDj8w=3D; b=kKR+4q8ipvIiKzOCOokQEx8n/ml7/BJ8doyTUBSTbPp9ekRkKNj6eH66+JY2+dsp56Fdyk0M FEsOG6C1jy6Q4mV+oKFPci/P2BeH9zRSZhFeBj6fagpH30kfYyRdoxb6; Authentication-Results: sj-dkim-5.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "'Joel M. Halpern'" , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > On Nov 2, 2006, at 3:11 AM, Aki Niemi wrote: > > > Rants are so much fun. Another inline. > > Excellent rant, which could be summarized as "deprecate UDP". > I think that's an interesting suggestion. It almost sounds like > something I might have said myself at some timeIt would also > solve our large-responses problem, and our "oh my god my request > is too big to send in one packet" problem, and a bazillion > other things. > > It does have a bit of susceptibility to the RST DOS attack of TCP to > think about, If you're worried about that attack, you should be equally concerned about a nearly-identical attack on UDP that seems apparent -- draft-jung-sipping-authentication-spit-00 discusses a solution, but as I have posted earlier, if a UA expects all messages from its proxy contain Authentication-Info, we may be able to solve the same problem. > something that DTLS does not suffer from. But > other than that and inertia I can think of no good reason to > keep using UDP. To be clear, DTLS does not solve the large UDP problem -- DTLS has support for fragmentation, but only for the TLS handshake itself. We could, and maybe should, invent some framing so that DTLS could solve that problem, too. Adding such framing might be appropriate if/when draft-jennings-sip-dtls-02.txt becomes a WG item. > I'll note however that Robert reports that SIPit seems to indicate > that most implementations are dealing with fragmented UDP just fine > and nobody is actually noticing any problems with large packets, so > we may be "burning a straw witch" when we worry about fragmentation. > Personally, I'm far more worried about rampant complexity. That conflicts with the conclusion of draft-heffner-frag-harmful-02, which is in IETF last call. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 18:20:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8HI-0003QM-Eq; Fri, 03 Nov 2006 18:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8HG-0003QH-E1 for sip@ietf.org; Fri, 03 Nov 2006 18:16:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8HF-0001mH-3W for sip@ietf.org; Fri, 03 Nov 2006 18:16:46 -0500 Received: by ug-out-1314.google.com with SMTP id 72so484898ugd for ; Fri, 03 Nov 2006 15:16:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VwbMav2kOFNNxDGNLr/GJWDoFZPmEKNrjLh1oB51v+xJDka5Dyqe/5f7Ge7uIKJYBMqV+9xv/AR5HtfFO+nmHNTw0uiM4bZuiyc42qz0pNlYuEdlXjdHwam88wfeVHr6vR8+MJbcqEMvGt/7/pWKII2RaYll7y/wn4fd1mLKGeo= Received: by 10.78.128.11 with SMTP id a11mr1558817hud.1162595803709; Fri, 03 Nov 2006 15:16:43 -0800 (PST) Received: by 10.78.200.9 with HTTP; Fri, 3 Nov 2006 15:16:43 -0800 (PST) Message-ID: <953beacc0611031516k5231eeccqc644c13e7b83cbcd@mail.gmail.com> Date: Fri, 3 Nov 2006 15:16:43 -0800 From: "Rohan Mahy" To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Outbound-05: Editorial comments In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59404549344@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5EB80D22825EEE42872083AD5BFFB59404549344@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, Comments inline. On 10/30/06, Christer Holmberg (JO/LMF) wrote: > > Hi, > > Some editorial comments on outbound-05: > > Abstract: > --------- > > Instead of: > > "It also defines keep alive behaviors needed to keep NAT bindings open" > > ...I propose that we should say something like: > > "It also defines how SIP implements the STUN keepalive usage > [reference]" I-D/RFC formatting guidelines prohibit references in the Abstract. > Introduction: > ------------- > > Instead of: > > "The key idea of this specification" > > ...I propose that we should say something like: > > "The key idea of the outbound mechanism defined in this specification" > > Because, the are two key ideas in the spec: the outbound mechanism and > the STUN keepalive for SIP. No, the key idea in this specification is about oubound-initiated flows. STUN is a detail specified in a single chapter. > Instead of: > > "This mechanism also uses a keep alive mechanism over each flow so that > the UA can detect when a > flow has failed." > > ...I propose that we should say something like: > > "This specification also defines how SIP implements the STUN keepalive > usage. The keepalive mechanism is used by outbound to keep NAT bindings, > and to allow the UA to detect when a flow has failed. The keepalive > mechanism can also be used as a stand-alone function, or together with > other SIP extensions". I am fine with your first two sentences. > Chapter 3.5: > ------------ > > Instead of: > > "This specification describes using STUN [I-D.ietf-behave-rfc3489bis] > over the same flow as the SIP traffic to > perform the keepalive." > > ...I propose that we should say something like: > > "This specification describes the usage of the STUN keepalive usage > [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP traffic to > perform the keepalive. The SIP implementation of the STUN keepalive > usage is described in chapter 8 of this specification." This change just seems to add extra bulk to the spec. I don't see how this makes anything clearer. > Chapter 8: > ---------- > > In generel I think this chapter is good, but I don't think we should > talk about "flows" here, becuase the chapter is not part of outbound > itself (I also still strongly think that we should define a flag which > can be inserted in Path/Service-Route, but that issue is discussed in > another thread). > > So, I think it would be enough to say something like: > > "The STUN messages can be used to verify that connectivity is still > available, and to provide periodic keepalives in order to keep NAT > bindings open. > > ...and: > > "A SIP node MUST NOT send STUN requests unless it has an explicit > indication that the target next hop SIP server claims to support STUN." All the text in this section was put there to satisfy someone. We had consensus on the list to go forward with the proposal I described with respect to STUN. I believe this section accurately expresses that consensus and the email I sent out describing what I would do. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 20:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgAgn-0002uH-76; Fri, 03 Nov 2006 20:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgAgl-0002uB-GJ for sip@ietf.org; Fri, 03 Nov 2006 20:51:15 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgAgk-0006R4-4Y for sip@ietf.org; Fri, 03 Nov 2006 20:51:15 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2006 17:51:13 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANOAS0VAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="47815955:sNHT3299438008" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA41pCBo012701; Fri, 3 Nov 2006 20:51:12 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA41pAYJ017520; Fri, 3 Nov 2006 20:51:10 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 20:51:10 -0500 Received: from [192.168.1.103] ([10.86.243.8]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 20:51:09 -0500 Message-ID: <454BF20C.20608@cisco.com> Date: Fri, 03 Nov 2006 20:51:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com> In-Reply-To: <4549B645.50907@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2006 01:51:09.0476 (UTC) FILETIME=[B30BC640:01C6FFB3] DKIM-Signature: a=rsa-sha1; q=dns; l=3570; t=1162605072; x=1163469072; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20SIP=20as=20an=20alternative=20to=20IKE?, =20was=3A=20Re=3A=20[Sip ]=20RE=3A=20TLS=20meaning |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DPDUfR6pqeG7oxbPsXaWMo8977/A=3D; b=BWqwUqmep2Opj66FaTmqPvqHG22Qp/61vsfNH9jgsjlIl0w7dvlw6+inPthghzgIgllseUEr rqFZfhXkWIInlu5Ez5pDTURfGoSE/U9TJ2CbFSzW48PqgTp7xK0HK4jP; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "Joel M. Halpern" , 'IETF SIP List' , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Aki Niemi wrote: >>If TCP is the stumbling block to using TLS in IMS, then DTLS to me would >>be a blessing. Nothing would please me more than to deprecate the specs >>that define this nightmare. Two in particular - the seemingly innocuous >>RFC4169 which opens the door for sip-as-a-keying-protocol, and the even >>more horrible RFC3329, which hides its real agenda of adding bid-down >>prevention to SIP-the-IPSec-keying-protocol. Once deprecated, we can >>tell 3gpp to use SIP over DTLS in R8. > > > > In all fairness, I don't remember you or anyone else offering DTLS as an > alternative ~5 years ago when all this was specified. Of course not; it didnt exist. The alternative was TLS and that was deemed unacceptable. > Nor did we have > the PSK cipher suite for TLS, which IMO would go far in solving the IMS > first-hop problem in a much, much cleaner way. > > Being involved in the work you mention, I would be first to admit it's > an Utter Hack, and nothing would please me more than to see it go away. Great! SO lets work on it! > What's worse is that the way it's being implemented and deployed manages > to lose the one bit that is actually worth something, i.e., the bid-down > protection of sec-agree. I think we managed to lay in enough bugs in > there, too, that interop is pretty horrible. But hey, live and learn. > > That said, the root of all evil here is UDP. It still escapes me why > people insist on dragging that baggage around when all I see are cons > with using UDP as transport. If anything, that's a massive layer > violation to run SIP over UDP, and then replicate the state machine of > TCP in SIP. A while ago there was speculation on the SIP WG list about > defining delayed ACK for SIP to get around some weird error condition > (pardon me, the details escape me ATM). That to me would have been the > last spool that completes the reinvented wheel. > > People have cited performance problems for servers having to scale up > with a huge number of TCP connections. I don't buy that. People have > cited problems with mobile handsets not being able to handle TCP. Bogus. > Even the low-end phones today handle TCP and run TLS just fine. If > someone has a phone that doesn't, well, perhaps it's time to upgrade. The oft-cited problem is one of performance for real-time services, i.e., the delays in call setup that tcp would cause. I'm not enough of a TCP expert to know whether any of these have merit or are just bogus paranoia. > > What's nice about TCP is that the performance in presence of NAT tends > to be a lot better than with UDP. In wide area cellular, using UDP > keepalives will drain the battery unless you have the phone connected to > a charger. And that pretty much defeats the purpose of a *mobile* device. Sure; though even with TCP its still bad for wireless. NAT between a mobile device and the radio network is just an awful topology. Recently Dan submitted a draft which addresses the only solution I've seen that allows a good solution for cellular here: http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-00.txt -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBEB-0002NZ-K9; Fri, 03 Nov 2006 21:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBE9-0002Kn-Dt for sip@ietf.org; Fri, 03 Nov 2006 21:25:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBE6-0003Pl-2j for sip@ietf.org; Fri, 03 Nov 2006 21:25:45 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 18:25:41 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="85358840:sNHT48753423" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PfMn031948; Fri, 3 Nov 2006 18:25:41 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42Pfin015832; Fri, 3 Nov 2006 18:25:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:40 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:40 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <728F6C8E-329E-442A-AA6E-3F6E66CD732E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:44 -0800 To: SIP X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:40.0450 (UTC) FILETIME=[85715420:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=1532; t=1162607141; x=1163471141; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-gurbani-sip-lrage-udp-response-00; X=v=3Dcisco.com=3B=20h=3Dd7d/LeK2NjgSRHMeYBdZKkDhP5s=3D; b=mU97MhSNaOP8Z5m1xIqLlSv/jTFTKw6k7nIOZBF0QnIy6PuW/XeQWZKa7olcxyZH/Yo42+tb fS1dvERKsddVi7MmVfhqxgS44I0CnniYzQYGulP2J3OpwCnwcU2yoBgE; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Vijay Gurbani Subject: [Sip] draft-gurbani-sip-lrage-udp-response-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One thing that really confused me about this draft was if seemed to use the term "congestion control" when what it actually meant "can deliver large packets". These seem to be two very separate things. I think fragmentation reassembly actual does work thought most NATs. The basic machoism seems broken. The advice that when a UAC gets a 140 or 141 may later try with TCP does not make any sense to me. The UA might be able to use TCP to the first proxy but there is no way to tell that proxy to not use UDP to the next. Since this approach does not work, on the topic of the other proposals Section 4.1 - it seems this one fails in usual HERFP failure mode if one response is big and others are not. I think this problem should be mentioned. Section 4.2 - I have no idea what you are talking about here. Can you explain how this option would work? Section 4.3 - Here you send a single possible request and expect back a single response but if it forks you might get back the response plus *several* requests in reverse direction. The experience with early media has been three are a lot of complications with this. It might be the best approach but a generic description of it is pretty hard. I will point out this is exactly what we are doing on all the case where we do need large responses (i.e. SUB/NOT) so it might be that we basically already adopted this solution. It was not clear to me who received the 140, what they did with it, or why they cared. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBE0-0002K2-DE; Fri, 03 Nov 2006 21:25:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBDz-0002Ju-EO for sip@ietf.org; Fri, 03 Nov 2006 21:25:35 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBDx-0003PN-3o for sip@ietf.org; Fri, 03 Nov 2006 21:25:35 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 18:25:33 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="754548923:sNHT49395906" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PWoJ010762 for ; Fri, 3 Nov 2006 18:25:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42PWin015791 for ; Fri, 3 Nov 2006 18:25:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:32 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:32 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:35 -0800 To: SIP X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:32.0310 (UTC) FILETIME=[80974360:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=1656; t=1162607132; x=1163471132; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-rosenberg-sip-outbound-discovery-mid-dialog=20-=20dhcp=20overide=2 0or=20not?; X=v=3Dcisco.com=3B=20h=3DbCikUKpzI78uaTRUzeoui5JTrz0=3D; b=HSlIU5zFqHTxJmyprZ69tN8EXMp8sQUBtYsMiRDPvnO3pbRwbHRIhHmOf1kzSgN9Rc4K7+Xe WeCfkeewFm/FgLyn7gZbsvRxMwLa/eGS2moorVoUkM2Up6BU3jFyv4Ik; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Sip] draft-rosenberg-sip-outbound-discovery-mid-dialog - dhcp overide or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is an issues about using outbound proxies discovered thought DHCP where it is not clear to me what we want the solution to be. Once we are clear on the desired behavior it is trivial to get the draft to provide that. Let me try to describe the problem... If a phone has no configuration, no proxies, no aor etc and it gets connected to the networks and finds out a proxy name via DHCP and uses that to make outbound calls, I have no problem that is great. The question is what happens with a phone that is configured, has a AOR, credentials, etc. One view is that if DHCP returns a result, you use that as the outbound. The argument will be made that this is the way you discover the proxy in the hotel that lets you traverse the firewall. But consider the security implications of this. It means that anyone that spoof a DHCP response at a wireless hot spot can force you to connect to them. Even if you are doing SIPS, you will pass all your signaling through the attackers proxy and they will be able to see it all. Perhaps there is a part of this that I am missing but the more I think about it, it does not seem like you want to actually use outbound proxies that were discovered via DHCP. (Note this has nothing to do with a home proxy telling you to use a proxy in a visited network - here someone you trust, the home proxy, told you to trust the proxy in the visited network) -------- One other trivial note - when talking about the names in the certificates, I think the text needs to be updated a bit to cover certificates that have more than one name in them _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBEB-0002NZ-K9; Fri, 03 Nov 2006 21:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBE9-0002Kn-Dt for sip@ietf.org; Fri, 03 Nov 2006 21:25:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBE6-0003Pl-2j for sip@ietf.org; Fri, 03 Nov 2006 21:25:45 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 18:25:41 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="85358840:sNHT48753423" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PfMn031948; Fri, 3 Nov 2006 18:25:41 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42Pfin015832; Fri, 3 Nov 2006 18:25:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:40 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:40 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <728F6C8E-329E-442A-AA6E-3F6E66CD732E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:44 -0800 To: SIP X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:40.0450 (UTC) FILETIME=[85715420:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=1532; t=1162607141; x=1163471141; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-gurbani-sip-lrage-udp-response-00; X=v=3Dcisco.com=3B=20h=3Dd7d/LeK2NjgSRHMeYBdZKkDhP5s=3D; b=mU97MhSNaOP8Z5m1xIqLlSv/jTFTKw6k7nIOZBF0QnIy6PuW/XeQWZKa7olcxyZH/Yo42+tb fS1dvERKsddVi7MmVfhqxgS44I0CnniYzQYGulP2J3OpwCnwcU2yoBgE; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Vijay Gurbani Subject: [Sip] draft-gurbani-sip-lrage-udp-response-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One thing that really confused me about this draft was if seemed to use the term "congestion control" when what it actually meant "can deliver large packets". These seem to be two very separate things. I think fragmentation reassembly actual does work thought most NATs. The basic machoism seems broken. The advice that when a UAC gets a 140 or 141 may later try with TCP does not make any sense to me. The UA might be able to use TCP to the first proxy but there is no way to tell that proxy to not use UDP to the next. Since this approach does not work, on the topic of the other proposals Section 4.1 - it seems this one fails in usual HERFP failure mode if one response is big and others are not. I think this problem should be mentioned. Section 4.2 - I have no idea what you are talking about here. Can you explain how this option would work? Section 4.3 - Here you send a single possible request and expect back a single response but if it forks you might get back the response plus *several* requests in reverse direction. The experience with early media has been three are a lot of complications with this. It might be the best approach but a generic description of it is pretty hard. I will point out this is exactly what we are doing on all the case where we do need large responses (i.e. SUB/NOT) so it might be that we basically already adopted this solution. It was not clear to me who received the 140, what they did with it, or why they cared. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBE0-0002K2-DE; Fri, 03 Nov 2006 21:25:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBDz-0002Ju-EO for sip@ietf.org; Fri, 03 Nov 2006 21:25:35 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBDx-0003PN-3o for sip@ietf.org; Fri, 03 Nov 2006 21:25:35 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 18:25:33 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="754548923:sNHT49395906" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PWoJ010762 for ; Fri, 3 Nov 2006 18:25:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42PWin015791 for ; Fri, 3 Nov 2006 18:25:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:32 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:32 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:35 -0800 To: SIP X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:32.0310 (UTC) FILETIME=[80974360:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=1656; t=1162607132; x=1163471132; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-rosenberg-sip-outbound-discovery-mid-dialog=20-=20dhcp=20overide=2 0or=20not?; X=v=3Dcisco.com=3B=20h=3DbCikUKpzI78uaTRUzeoui5JTrz0=3D; b=HSlIU5zFqHTxJmyprZ69tN8EXMp8sQUBtYsMiRDPvnO3pbRwbHRIhHmOf1kzSgN9Rc4K7+Xe WeCfkeewFm/FgLyn7gZbsvRxMwLa/eGS2moorVoUkM2Up6BU3jFyv4Ik; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Sip] draft-rosenberg-sip-outbound-discovery-mid-dialog - dhcp overide or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is an issues about using outbound proxies discovered thought DHCP where it is not clear to me what we want the solution to be. Once we are clear on the desired behavior it is trivial to get the draft to provide that. Let me try to describe the problem... If a phone has no configuration, no proxies, no aor etc and it gets connected to the networks and finds out a proxy name via DHCP and uses that to make outbound calls, I have no problem that is great. The question is what happens with a phone that is configured, has a AOR, credentials, etc. One view is that if DHCP returns a result, you use that as the outbound. The argument will be made that this is the way you discover the proxy in the hotel that lets you traverse the firewall. But consider the security implications of this. It means that anyone that spoof a DHCP response at a wireless hot spot can force you to connect to them. Even if you are doing SIPS, you will pass all your signaling through the attackers proxy and they will be able to see it all. Perhaps there is a part of this that I am missing but the more I think about it, it does not seem like you want to actually use outbound proxies that were discovered via DHCP. (Note this has nothing to do with a home proxy telling you to use a proxy in a visited network - here someone you trust, the home proxy, told you to trust the proxy in the visited network) -------- One other trivial note - when talking about the names in the certificates, I think the text needs to be updated a bit to cover certificates that have more than one name in them _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBDg-0001rj-2N; Fri, 03 Nov 2006 21:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBDe-0001ln-IY for sip@ietf.org; Fri, 03 Nov 2006 21:25:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBDc-0003My-Bl for sip@ietf.org; Fri, 03 Nov 2006 21:25:14 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 18:25:12 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="85358761:sNHT71855091" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PBli031689; Fri, 3 Nov 2006 18:25:11 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42PBin015670; Fri, 3 Nov 2006 18:25:11 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:11 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:11 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <50B1CBA96870A34799A506B2313F26670A38D725@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670A38D725@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:14 -0800 To: SIP , John Elwell X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:11.0169 (UTC) FILETIME=[73FD6710:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=12890; t=1162607111; x=1163471111; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Rejecting=20connected=20identity=20; X=v=3Dcisco.com=3B=20h=3Dird6inuwgMxMLfWY7m2Nols3Giw=3D; b=nOBP5zOroxqDOC8GddIBBIG+lbrJJAOLyNLk5EgMrYYBzDFjoOKF6VZfI/9WaJ5uv2QgoDbX +mh8iFsuwRKHZkegDwjxfkyrZ/M7VhWXuipV5Keepb+LSt0fCbVg6GrS; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: Subject: [Sip] Rejecting connected identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We are going to have to thing very carefully about the security implications of section 4.6 in the latest 02 version - I'm worried we are removing the information that would allow a downstream sip device to make the appropriate authorization decision - anyways - lets talk in San Diego. On Oct 29, 2006, at 1:41 AM, Elwell, John wrote: > Cullen, > > See below. > > John > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 28 October 2006 16:42 >> To: Elwell, John >> Cc: Jon Peterson; SIP; Paul Kyzivat >> Subject: Re: Rejecting connected identity (was RE: >> draft-ietf-sip-connecte d-id entity-01 comments) >> >> >> This is clearly hard and I would like to talk about it in person and >> see if we can sort it out. A few things I was thinking about ... >> >> a) are there any practical scenarios where the initial invite >> identity would have worked then the later mid dialog one fails in >> this way > [JRE] Yes, the initial mid-dialog request will be in the reverse > direction, > so a different Authentication Service and a different Verifier. > >> >> b) If the authentication verification fails and I have an >> authorization policy at proxy that says don't accept unverified >> calls, then clearly it needs to fail - even if it is retried > [JRE] Agreed. > >> >> c) should we consider something like, in the case of an error like >> this, a UA could retry as an anonymous call > [JRE] I guess the UAC would need to use anonymous.invalid - then I > think it > could work. Using anonymous@example.com would not work, since a > proxy-located Authentication Service for example.com might still > add an > Identity header field. > >> >> Let's talk in San Diego... > [JRE] Yes, indeed, we should try to chat before the SIP session, which > fortunately is late in the week. > >> >> On Sep 26, 2006, at 1:02 PM, Elwell, John wrote: >> >>> Cullen, Jon, >>> >>> In case you missed this (it wasn't addressed directly to >> you), I would >>> greatly appreciate an opinion from each of you on this remaining >>> issue in >>> connected-identity. Just to summarise, RFC 4474 leaves it >> up to policy >>> whether to return a 428 response if Identity is missing, but >>> mandates the >>> sending of a 436, 437 or 438 response for certain errors >> arising while >>> verifying the signature. It seems that for mid dialog requests this >>> behaviour could be harmful. What does the UAC for the mid dialog >>> request do >>> if it receives 436, 437 or 438? If the mid-dialog request was >>> solely for the >>> purpose of connected identity, it can give up and allow the >> call to >>> continue >>> as is. But if the request was for some other purpose (e.g., >>> renegotiating >>> the session because of hold, say, or session timer refresh), the >>> UAC really >>> wants it to work. For the normal case where the Authentication >>> Service is at >>> a proxy, not at the UAC, the UAC cannot force the Authentication >>> Service to >>> refrain from putting this unverifiable signature in the mid-dialog >>> request, >>> so any attempts to repeat the request would most likely be doomed >>> to getting >>> the same response. >>> >>> It seems there are three things we could do, none very attractive: >>> 1. Get connected-identity to modify the procedures of RFC 4474 for a >>> verifier by softening the requirements for sending 436, 437 >> and 438 in >>> response to mid-dialog requests. But then a mid-dialog >> request from >>> a rogue >>> source would be accepted. >>> 2. Say that the Authentication Service should omit the signing of >>> mid-dialog >>> requests if a previous attempt has resulted in 436, 437 or >> 438. But >>> this >>> implies statefulness at the AS. >>> 3. Accept the fact the mid-dialog requests can fail in this way and >>> therefore things like session refresh and session renegotiation >>> cannot be >>> done, probably resulting in call failure. Sounds bad, but it is no >>> different >>> from an initial INVITE request, where there is nothing the UAC can >>> do if the >>> AS inserts an Identity header that gets rejected with 436, >> 437 or 438. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 22 September 2006 19:26 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; SIP >>>> Subject: Re: Rejecting connected identity (was RE: >>>> draft-ietf-sip-connected-id entity-01 comments) >>>> >>>> John, >>>> >>>> I want to hear what others, especially Jon and Cullen, have >>>> to say about >>>> this. >>>> >>>> It is of some concern to me that a call might fail because of some >>>> problem with the identity mechanism when the same call might have >>>> succeeded in the absence of any identity. >>>> >>>> But possibly the solution to this is policy in the >>>> implementation of the >>>> verifier. What to do in the case of the conditions that >> lead to these >>>> errors could be configurable in the verifier: either to >> generate the >>>> error or simply to remove the identity info from the >> message. And the >>>> policy could conceivably vary based on attributes of the >>>> message, such >>>> as whether it is in-dialog or not. >>>> >>>> Does it require a change to 4474 to permit that kind of policy? >>>> >>>> It would be annoying if the end user had no control over the >>>> insertion >>>> and verification of identity, and it resulted in calls >>>> failing that the >>>> user would like to permit. But I suppose that is itself a policy >>>> decision. There are certainly enterprises that want to exert >>>> that kind >>>> of control over what users are permitted to do. >>>> >>>> Paul >>>> >>>> Elwell, John wrote: >>>>> Paul, >>>>> >>>>> I agree with most of your points, and on reflection I think >>>> I agree that the >>>>> solution has to be with the verifier. >>>>> >>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>> 'Use Identity >>>>> Header' response is concerned, because that is left to >>>> policy, so we could >>>>> say in connected-identity that policy should be to not send 428. >>>>> >>>>> However, 436, 437 and 438 responses are all a problem, >>>> because RFC 4474 says >>>>> that they MUST be sent under respective conditions. >>>> Interestingly, though, >>>>> there are other failure scenarios that can arise from the >>>> procedures of >>>>> section 6 of RFC 4474 for which no normative statement is >>>> given on how to >>>>> respond, e.g. invalid Date header field, signer not >>>> authoritative for the >>>>> domain. >>>>> >>>>> So one way to solve the present problem would be for the >>>> connected-identity >>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>> of mid-dialog >>>>> requests. I guess this would mean that it would update RFC >>>> 4474 as well as >>>>> updating RFC 3261. But I don't like this, because it seems >>>> to remove some of >>>>> the security properties of RFC 4474. >>>>> >>>>> Another way would be to accept that 436, 437 and 438 >>>> responses will be sent, >>>>> and failure to verify a signature will therefore result in >>>> inability to >>>>> process the UPDATE or re-INVITE request, and hence if the >> UPDATE or >>>>> re-INVITE request was for some other purpose such as >>>> session timer refresh >>>>> or modifying the session, that action will fail. Then the >>>> call will fail (in >>>>> the case of inability to refresh the session timer) or the session >>>>> modification will fail. I guess this is somewhat analogous >>>> to caller ID >>>>> verification failure in an INVITE request - it is >>>> impossible to establish a >>>>> call if verification fails. Moreover, the UAC has no >>>> ability to rectify the >>>>> situation, since it is at the mercy of a proxy-based >>>> Authentication Service >>>>> that puts a rogue Identity header field in every request. >>>> In the connected >>>>> identity case, the only difference is that the call is >>>> already established >>>>> but is likely to fail if verification fails. >>>>> >>>>> Of course, if the mid-dialog request is indeed from the >>>> wrong source, then >>>>> sending a 436, 437 or 438 response is indeed the correct >>>> thing to do, and >>>>> overriding the verification procedures of RFC 4474 would >>>> indeed be the wrong >>>>> thing to do. So perhaps we just have to accept that these >>>> response codes can >>>>> be received and will lead to failure. >>>>> >>>>> So, my preferred way forward is simply to recommend not >>>> sending a 428 and >>>>> accept the consequences of other responses that the >>>> verifier might send. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: 22 September 2006 15:13 >>>>>> To: Elwell, John >>>>>> Cc: Cullen Jennings; SIP >>>>>> Subject: Re: [Sip] RE: >>>> draft-ietf-sip-connected-identity-01 comments >>>>>> >>>>>> >>>>>> >>>>>> Elwell, John wrote: >>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>> When an Update is sent. Are there any conditions under which >>>>>>>> it might >>>>>>>> be rejected. Bad identity for example. I think that >>>> might need a >>>>>>>> little discussion and also what the UA does when it sends >>>>>> an update >>>>>>>> with a no identity and it gets rejected. >>>>>>> [JRE] A very good point. We don't want to get to a >>>>>> situation where it is >>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>> purposes such as >>>>>>> session timer refresh or session re-negotiation) just >>>>>> because connected >>>>>>> identity fails. >>>>>>> My proposed fix is as follows: >>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>> with 428 'Use >>>>>>> Identity Header'. >>>>>> I'm not sure about this. At the least I think this one needs >>>>>> some clear >>>>>> explanation of the SHOULD NOT - about the conditions when >>>> it can be >>>>>> violated. >>>>>> >>>>>> I see this as somewhat analogous to doing a digest >> challenge on an >>>>>> in-dialog request. In some cases it is the right thing to do. >>>>>> >>>>>> A UA that imposes such a requirement will be limited in what >>>>>> it can do, >>>>>> but that may still be right in some cases. >>>>>> >>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>> Identity header field >>>>>>> to a mid-dialog request if a previous request on that >>>>>> dialog has resulted in >>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>> 438 'Invalid >>>>>>> Identity Header'. >>>>>> This requirement would force the authentication service to >>>> be dialog >>>>>> stateful, which is not ideal. Better to push the state >>>> back into the >>>>>> sender of the request. This may require a way for the UAC >>>> to tell the >>>>>> authentication service not to act. >>>>>> >>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>> results in one of >>>>>>> these responses if the mid-dialog request was not solely >>>>>> for the purpose of >>>>>>> connected identity. If solely for the purpose of connected >>>>>> identity there is >>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>> any further >>>>>>> action". >>>>>> This seems wrong to me. >>>>>> >>>>>> I think that the remedy to these is in the verifier. The >>>>>> purpose of the >>>>>> verifier is ultimately to drive an authorization decision. If >>>>>> authorization would succeed in the absence of the >>>> identity, then the >>>>>> request should be permitted to continue as if the identity >>>>>> was not present. >>>>>> >>>>>> Unfortunately this would seem to require a revision to 4474 >>>>>> even though >>>>>> the paint is hardly dry on it. >>>>>> >>>>>> If this is done, then there is no need of a mechanism to >> cause the >>>>>> authentication service *not* to authenticate. If this is >>>> *not* done, >>>>>> then that need remains, which will still require a >> change to 4474. >>>>>> >>>>>> 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 >>>>>> >>>>> >>>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBEG-0002RZ-M9; Fri, 03 Nov 2006 21:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBEE-0002On-Rf for sip@ietf.org; Fri, 03 Nov 2006 21:25:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBED-0003QN-8i for sip@ietf.org; Fri, 03 Nov 2006 21:25:50 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 18:25:49 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="754548968:sNHT45666464" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PmnM002856 for ; Fri, 3 Nov 2006 18:25:48 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA42PmW6021384 for ; Fri, 3 Nov 2006 18:25:48 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:48 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:48 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <449A7F93-9156-434A-9639-8403C946D5C6@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:51 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:48.0357 (UTC) FILETIME=[8A27D750:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=264; t=1162607148; x=1163471148; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:ietf-sip-connect-reuse; X=v=3Dcisco.com=3B=20h=3DovOVw2sSaDL8Ta5M3ylbgI15uyI=3D; b=nRlGFL0SHDxK3sRKUNyNtPqmsdC005w2IKd/zPj4KFalqRe2aZlsgn7iQ5ulCgz64oxwhW8a LILfqr7mTg3EvxuJryipudo3umWYu6M9I67ZEqKfNmbXWHygDd3IKl//; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] ietf-sip-connect-reuse X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like section 8. The TCP behavior seems to contradict outbound. The authors of outbound and reuse should get it^H^H together some time :-) It seems that what a proxy should do when there is no alias flag is the same as when there is an alias flag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 03 21:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBDo-0002Gw-BP; Fri, 03 Nov 2006 21:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBDm-0002Gq-Lo for sip@ietf.org; Fri, 03 Nov 2006 21:25:22 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBDk-0003NR-Bi for sip@ietf.org; Fri, 03 Nov 2006 21:25:22 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2006 18:25:20 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJKIS0WrR7PEh2dsb2JhbACMSwEBAQgOKg X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="350001590:sNHT24049492" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42PJ0N010665; Fri, 3 Nov 2006 18:25:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA42PJW4021241; Fri, 3 Nov 2006 18:25:19 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:19 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:25:19 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <0064180D-AFB6-43F5-A9E8-AF4345FBA186@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP , Vijay Gurbani From: Cullen Jennings Date: Fri, 3 Nov 2006 18:25:22 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:25:19.0200 (UTC) FILETIME=[78C6D600:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=878; t=1162607119; x=1163471119; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-gurbani-sip-domain-certs; X=v=3Dcisco.com=3B=20h=3Dvbl3gW2GcRXXWLxXi2eEWn+FZSI=3D; b=Uju1PMpaGrqlo4fZtTDSzde3XfuIT0UQbwhvFw2CvSmklAbK6FU6+0+E1/zeIcaiF6O9kXEJ Uw8Pr1rEC/2W8dE/+WBnmg+RhooKD1Tp7JSv2ySClDJBU+AbhKdZYZcE; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Sip] draft-gurbani-sip-domain-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There some parts of the draft I like but some parts that seem strange to me ... We agree there are cases where we connect to a conical name for the domain and clearly this name will need to be in the cert. In some cases, a proxy may choose to put a different name in a record route, in that case we will need that name in the cert as well. Because of this clients need to be able to receive certs with one or more names. A proxy needs to have a cert with the names it uses - no more, no less. We should not assume that a building a proxy farm necessarily involves record routes names that are different that the domain name - some do - some don't. The trying to say if the name is URI type vs DNS type in seems totally orthogonal from anything this draft is trying to accomplish. For the stuff here, who cares, seems like either works. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 04 00:47:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEKQ-0005mC-6i; Sat, 04 Nov 2006 00:44:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEKO-0005m1-PF for sip@ietf.org; Sat, 04 Nov 2006 00:44:24 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgEKN-000167-G1 for sip@ietf.org; Sat, 04 Nov 2006 00:44:24 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA45iL821419 for ; Sat, 4 Nov 2006 00:44:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Nov 2006 23:44:24 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C273@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Null Encryption ciphers Thread-Index: Acb/1Eh4yOzDcAhyRZOz0jWvE0YL3Q== From: "Samir Srivastava" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] Null Encryption ciphers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0707030093==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0707030093== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FFD4.46A9BAB5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FFD4.46A9BAB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-03.txt define NULL Encryption cipher where confidentiality is not permitted. I don't know which geographic regions mandated it. Hop By hop nature of SIP might mandate the cipher exposure to it due to the above itself .... =20 Thx Samir ------_=_NextPart_001_01C6FFD4.46A9BAB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Null Encryption ciphers

Hi,

  http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-nul= l-03.txt define NULL = Encryption cipher where confidentiality is not permitted.  I don't = know which geographic regions mandated it.

  Hop By hop nature of SIP might = mandate the cipher exposure to it due to the above itself = ….
 
Thx
Samir

------_=_NextPart_001_01C6FFD4.46A9BAB5-- --===============0707030093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0707030093==-- From sip-bounces@ietf.org Sat Nov 04 01:04:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEb9-0005w2-36; Sat, 04 Nov 2006 01:01:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEb7-0005vu-8I for sip@ietf.org; Sat, 04 Nov 2006 01:01:41 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgEb5-0004OM-U7 for sip@ietf.org; Sat, 04 Nov 2006 01:01:41 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 038921E8C28; Fri, 3 Nov 2006 22:01:38 -0800 (PST) To: "Samir Srivastava" Subject: Re: [Sip] Null Encryption ciphers References: <62B9B0847CC47543B6B3B5E26BD268E60F74C273@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 03 Nov 2006 22:01:38 -0800 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F74C273@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 3 Nov 2006 23:44:24 -0600") Message-ID: <86velveon1.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi, > > http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-03.txt > define NULL Encryption cipher where confidentiality is not permitted. I > don't know which geographic regions mandated it. > > Hop By hop nature of SIP might mandate the cipher exposure to it due > to the above itself .... NULL ciphers are nothing new in TLS. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 04 01:21:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgErs-0001sq-Oq; Sat, 04 Nov 2006 01:19:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEro-0001gU-9y for sip@ietf.org; Sat, 04 Nov 2006 01:18:56 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgEmp-0007sn-60 for sip@ietf.org; Sat, 04 Nov 2006 01:13:48 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA46DT822888; Sat, 4 Nov 2006 01:13:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Null Encryption ciphers Date: Sat, 4 Nov 2006 00:13:32 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C27A@zrc2hxm2.corp.nortel.com> In-Reply-To: <86velveon1.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Null Encryption ciphers Thread-Index: Acb/1rSaeJhRShmEQ8WQwA7+LoCiFAAARgnQ From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Where they are used.. If a proxy on the downstream side has to use the NULL ciphers (due to configuration etc), then Proxy should reject the REQUEST, letting the UAC know that request cannot be fullfilled with Confidentiality specially for MESSAGE method. Thx Samir =20 >-----Original Message----- >From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 >Sent: Friday, November 03, 2006 10:02 PM >To: Srivastava, Samir (SC100:8826) >Cc: IETF SIP List >Subject: Re: [Sip] Null Encryption ciphers > >"Samir Srivastava" writes: > >> Hi, >> >> http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-03.txt >> define NULL Encryption cipher where confidentiality is not=20 >permitted. =20 >> I don't know which geographic regions mandated it. >> >> Hop By hop nature of SIP might mandate the cipher exposure=20 >to it due=20 >> to the above itself .... > >NULL ciphers are nothing new in TLS. > >-Ekr > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 04 01:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgFQw-0004LK-Rh; Sat, 04 Nov 2006 01:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgFQv-0004LB-AN for sip@ietf.org; Sat, 04 Nov 2006 01:55:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgFQs-00061i-Lk for sip@ietf.org; Sat, 04 Nov 2006 01:55:13 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2006 22:55:10 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="339395994:sNHT55075908" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA46tAA3029784; Fri, 3 Nov 2006 22:55:10 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA46t4bF029090; Fri, 3 Nov 2006 22:55:05 -0800 (PST) From: "Dan Wing" To: "'Cullen Jennings'" , "'SIP'" Subject: RE: [Sip] draft-gurbani-sip-lrage-udp-response-00 Date: Fri, 3 Nov 2006 22:55:06 -0800 Message-ID: <0b7301c6ffde$2c158bf0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb/uNIQFedlOFRFSk+9AJRp2NYscgAI/ZSg In-Reply-To: <728F6C8E-329E-442A-AA6E-3F6E66CD732E@cisco.com> DKIM-Signature: a=rsa-sha1; q=dns; l=3285; t=1162623310; x=1163487310; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20draft-gurbani-sip-lrage-udp-response-00; X=v=3Dcisco.com=3B=20h=3DQPef+GgKEgnm7cwri5t4Nwroq64=3D; b=gUy0wXj2+Fi4X+hvkFFBmvD4ei9joDNczwj2RW46bCoh0/UwFjBzCNf9EKZQ2Z74Lq/ht5UX tGOfXoMuwC63XxAzV7xYEnT2zJZ5N4JhkrIERXG0q8d960xiroP4Ah1P; Authentication-Results: sj-dkim-7.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'Vijay Gurbani' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Section 2 of the document states: Note that UDP fragmentation and reassembly works unless there is a lossy link or there is a NAT between the communicating endpoints. but there are other cases where fragmentation breaks; see draft-heffner-frag-harmful-02.txt. I suggest that -heffner-frag-harmful- should be referenced by -gurbani-sip-large-udp-response. As to NATs working well with fragmentation, it's hard to say -- are the fragments in question sent in order, or out of order? (I'm told that Linux sends fragments out of order, on purpose.) Some NATs work just fine if packets arrive in order (the first fragment (containing the IP header) arrives first). But those NATs don't work well if a fragment arrives first -- they just drop the fragment, which means the entire IP datagram will never be completely reassembled. Other NATs hold onto fragments if the fragments arrive first, hoping for the arrival of the first fragment (containing the IP header). BEHAVE's NAT-UDP document specified the best behavior, but it's difficult to characterize the behavior of NATs in the wild. -d > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, November 03, 2006 6:26 PM > To: SIP > Cc: Vijay Gurbani > Subject: [Sip] draft-gurbani-sip-lrage-udp-response-00 > > > One thing that really confused me about this draft was if seemed to > use the term "congestion control" when what it actually meant "can > deliver large packets". These seem to be two very separate things. > > I think fragmentation reassembly actual does work thought most NATs. > > The basic machoism seems broken. The advice that when a UAC gets a > 140 or 141 may later try with TCP does not make any sense to me. The > UA might be able to use TCP to the first proxy but there is > no way to > tell that proxy to not use UDP to the next. > > Since this approach does not work, on the topic of the other proposals > > Section 4.1 - it seems this one fails in usual HERFP failure mode if > one response is big and others are not. I think this problem should > be mentioned. > > Section 4.2 - I have no idea what you are talking about here. > Can you > explain how this option would work? > > Section 4.3 - Here you send a single possible request and > expect back > a single response but if it forks you might get back the response > plus *several* requests in reverse direction. The experience with > early media has been three are a lot of complications with this. It > might be the best approach but a generic description of it is pretty > hard. I will point out this is exactly what we are doing on all the > case where we do need large responses (i.e. SUB/NOT) so it might be > that we basically already adopted this solution. > > It was not clear to me who received the 140, what they did with it, > or why they cared. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 04 02:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgFlB-000808-L1; Sat, 04 Nov 2006 02:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgFl9-000800-Jl for sip@ietf.org; Sat, 04 Nov 2006 02:16:07 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgFl8-0002P8-Bq for sip@ietf.org; Sat, 04 Nov 2006 02:16:07 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA47G3726220; Sat, 4 Nov 2006 02:16:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D on handling large UDP responses Date: Sat, 4 Nov 2006 01:16:06 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C28D@zrc2hxm2.corp.nortel.com> In-Reply-To: <1161179093.2751.38.camel@132-177-120-205.ip.sipit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: Acbyu5o7G1dflyKbRr+gs62L0U4BEANJGhjQ From: "Samir Srivastava" To: "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Scott, Sorry for the delayed response. In line. Thx Samir >-----Original Message----- >From: Scott Lawrence [mailto:slawrence@pingtel.com]=20 >Sent: Wednesday, October 18, 2006 6:45 AM >To: Srivastava, Samir (SC100:8826) >Cc: sip@ietf.org >Subject: RE: [Sip] I-D on handling large UDP responses > >On Mon, 2006-10-16 at 03:25 -0500, Samir Srivastava wrote: > >> The proposed mechanism can be used only for REQ/RSP. How can we=20 >> address the problems caused in 200 OK (Offer) and ACK=20 >(Answer) due to=20 >> UDP between some proxies ? In the current model, UAC gets the=20 >> complete Large 200 OK (with delayed arrival of 140/141 or you change=20 >> the current solution w.r.t. 140/141), but ACK follows the=20 >different IP hops etc... > >Are you asking how this helps to detect a lost ACK? If so, I=20 >don't think that it does, but a lost ACK will cause the final=20 >response to be resent, so you'll know anyway. Eventually the=20 >14x should arrive, providing a hint as to the possible=20 >problem. Besides, the only time the ACK is likely to be lost=20 >due to UDP fragmentation is if it has the SDP answer and is=20 >itself large, which the sender already knows. > Due to UDP hops etc in between, ACK can be lost... How can you enforce ACK not to be lost. Then you can either add Proxy-Require in ACK.. But This will contradict the 3261 Proxy-Require rule, as ACK should have the same Proxy-Require as that of INVITE... In my personal opinion, all this is complex. Additional Running code question, how many states it will introduce to all ready complex state m/c's (170, If I remember correctly are already there with complete PRACK, UPDATE etc... ) >> We might be doing congestion handling in SIP for UDP transports in=20 >> future, where some of it is provided by other transports. In=20 >my purist=20 >> mind, SIP messages are becoming huge, so UDP is no more=20 >relevant. UDP=20 >> was taken initially, as it was simple to transport short SIP message=20 >> at that time. > >I'm hoping that providing better diagnostics that show how UDP=20 >fails will cause end users to put pressure on vendors to=20 >support TCP and/or TLS. With Proxy-Require (tcp), providers using only UDP will start loosing the revenue and will be forced to upgrade. My good wish :-) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 07:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GghQY-0006nk-8q; Sun, 05 Nov 2006 07:48:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GghQW-0006nc-BC for sip@ietf.org; Sun, 05 Nov 2006 07:48:40 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GghQU-0002Mi-Ob for sip@ietf.org; Sun, 05 Nov 2006 07:48:40 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA5CmRLp027749; Sun, 5 Nov 2006 14:48:28 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 14:47:21 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 14:47:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 14:47:18 +0200 Message-ID: In-Reply-To: <454BF20C.20608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Thread-Index: Acb/tCiIjGuoK0JDTp+1j71LDIFyAABIT/DA From: To: , X-OriginalArrivalTime: 05 Nov 2006 12:47:20.0858 (UTC) FILETIME=[88A1A7A0:01C700D8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061105144829-6BD90BB0-6438F8ED/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: joel@stevecrocker.com, sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Jonathan Rosenberg wrote: > >Aki Niemi wrote: >>=20 >> >> In all fairness, I don't remember you or anyone else=20 >offering DTLS as=20 >> an alternative ~5 years ago when all this was specified. > >Of course not; it didnt exist. The alternative was TLS and=20 >that was deemed unacceptable. > The point is that 3GPP IMS tried to do the best it could with the tools available 5 years ago, and with the requirement of supporting both TCP and UDP. Now that we do have better tools and better understanding, I agree that it is possible to device a better solution.=20 >> Nor did we have >> the PSK cipher suite for TLS, which IMO would go far in solving the=20 >> IMS first-hop problem in a much, much cleaner way. >>=20 >> Being involved in the work you mention, I would be first to=20 >admit it's=20 >> an Utter Hack, and nothing would please me more than to see=20 >it go away. > >Great! SO lets work on it! > Yes, I think it would make sense to redefine the IMS security solution based on TCP, TLS, and TLS-PSK. From my point of view the biggest problem is that nowadays we have two main security specs for SIP authentication and first hop protection, one based on TLS and another based on IPSec. It is a burden to keep supporting both of them. I note however, that it is 3GPP who maintains the IMS specification, so any updates of this magnitude are subject to concensus there. But it would certainly help, if the IETF came up with a working solution meeting the IMS requirements.=20 >> That said, the root of all evil here is UDP. It still escapes me why=20 >> people insist on dragging that baggage around when all I see=20 >are cons=20 >> with using UDP as transport. If anything, that's a massive layer=20 >> violation to run SIP over UDP, and then replicate the state=20 >machine of=20 >> TCP in SIP. A while ago there was speculation on the SIP WG=20 >list about=20 >> defining delayed ACK for SIP to get around some weird error=20 >condition=20 >> (pardon me, the details escape me ATM). That to me would=20 >have been the=20 >> last spool that completes the reinvented wheel. >>=20 >> People have cited performance problems for servers having to=20 >scale up=20 >> with a huge number of TCP connections. I don't buy that. People have=20 >> cited problems with mobile handsets not being able to handle=20 >TCP. Bogus. >> Even the low-end phones today handle TCP and run TLS just fine. If=20 >> someone has a phone that doesn't, well, perhaps it's time to upgrade. > >The oft-cited problem is one of performance for real-time=20 >services, i.e., the delays in call setup that tcp would cause.=20 >I'm not enough of a TCP expert to know whether any of these=20 >have merit or are just bogus paranoia. > I don't call myself a TCP expert either, but I fail to see any major problem. If the UA maintains a persistent TCP connection with its edge proxy, the initial INVITE and any furhter messages can be send and received without any additional delay compared to UDP. Also, the problems that TCP can have over wireless links that lose packets, do not really show up with the kind of "lock-step" pattern that SIP has. All messages fit into one or two packets, and then the sender waits for something in return. So, even if packets are lost, the congestion windows etc. do not cause much harm, since you always ever have only one or two packets to send. It is a different thing if you'd send a big chunk of data over SIP, but then we're not talking about real-time anymore and besides you'd need to do that on top of a congestion-controlled transport anyway. >>=20 >> What's nice about TCP is that the performance in presence of=20 >NAT tends >> to be a lot better than with UDP. In wide area cellular, using UDP >> keepalives will drain the battery unless you have the phone=20 >connected to >> a charger. And that pretty much defeats the purpose of a=20 >*mobile* device. > >Sure; though even with TCP its still bad for wireless. NAT between a=20 >mobile device and the radio network is just an awful topology.=20 True. If the wireless access provider can use public addresses, no problem. If it can't, it can still put its *OWN* servers to the same private address space as where the mobile hosts are. But, if some other service provider who does not have anything to do with the access network wants to offer, say SIP, service, then there's going to be a NAT and the service provider can do nothing about it. (And even if there's no NAT, it's possible that there's a stateful firewall which is nearly as bad.) This is not a SIP specific problem at all, but is visible in any applications requiring the host to be reachable from the network side. SIP, however, makes things even worse by using UDP for signaling. The best we can do is to run SIP over TCP and mux RTP/RTCP into the same port. (And still it may not be good enough.) Markus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 08:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GghxV-0008GR-7J; Sun, 05 Nov 2006 08:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GghxT-0008GA-Fo for sip@ietf.org; Sun, 05 Nov 2006 08:22:43 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GghxO-0003Wa-SI for sip@ietf.org; Sun, 05 Nov 2006 08:22:43 -0500 Received: (qmail 32492 invoked by uid 0); 5 Nov 2006 13:23:43 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Nov 2006 13:23:43 -0000 Message-ID: <002501c700dd$71b41c30$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F019756B4@esebe103.NOE.Nokia.com> Subject: Re: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Date: Sun, 5 Nov 2006 14:22:29 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428504089==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0428504089== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C700E5.D32E82E0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C700E5.D32E82E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Erkki, You are right in the sense that *some* URI parameter is needed to distinguish between cases (1) and (2), but it needn't be the reg-id. In any case the specification in the current draft won't work, because the user part needs to be the same for cases (1) and (2). If we consider it acceptable that high availability does not work across vendors, then there is no need to standardize on any particular URI parameter. Regards, Jeroen ----- Original Message ----- From: Erkki.Koivusalo@nokia.com To: jbemmel@zonnet.nl ; jdrosen@cisco.com Cc: sip@ietf.org Sent: Wednesday, November 01, 2006 1:47 PM Subject: RE: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Hi Jeroen, But when reading the overview of the draft I came to a different understanding about the 'stickness' that this draft is trying to achieve. In order of decreasing preference: 1. The specific flow used for a dialog as indicated by the URI parameters added into Record-Route 2. Any flow registered by the UA as indicated by the user part of the URI as added to Path & S-R 3. Any proxy within the cluster as indicated by the host part of the URI as in initial REGISTER I did not find reg-id to be significant in any of those three options. The instance-id (together with username and the selected proxies for the outbound-proxy-set) is sufficient to identify any existing flow (as for item 2). In which use case a proxy should be able to prefer a specific flow with a specific reg-id ? I did not find any such use case in the draft. Regards, Erkki -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 01 November, 2006 14:02 To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); jdrosen@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Erkii, The idea is to create 'stickiness', to prefer using the same flow for all requests unless it fails. So in order of decreasing preference: 1. Flow with same reg-id 2. Flow with other reg-id 3. Flow towards same FQDN (proxy cluster) Note that the matching algorithm I describe below is incomplete, what is needed is a set of rules that result in the above order of preference (in other words, binary equality is insufficient, we need multiple degrees of equality i.e. exact match, partly specific match, weak match (sam FQDN) and no match) Regards, Jeroen ----- Original Message ----- From: Erkki.Koivusalo@nokia.com To: jbemmel@zonnet.nl ; jdrosen@cisco.com Cc: sip@ietf.org Sent: Wednesday, November 01, 2006 12:55 PM Subject: RE: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Hi, Actually I did not understand why the reg-id should be encoded into this URI at all. Could you please clarify the reason for its presence ? Or could the URI be constructed without the reg-id included to any part of the URI ? Regards, Erkki -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 28 October, 2006 18:55 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: [Sip] mid-dialog failover: need URI parameter for reg-id to avoidtriangular routing Jonathan, Regarding your outbound-discovery-mid-dialog draft: I believe it can work, but the example given in section 15 has some glitches and may result in sub-optimal routing. The backup flow from the UA x should have a different reg-id, say reg-id=*2* (instead of 1 as per the example in the draft). Assume there is also a user y registered, via proxy 1 and proxy 3. Then the connection table at the home proxy would look like TLS connection to 1: sip:outbound.example.com sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=stun TLS connection to 2: sip:outbound.example.com sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun TLS connection to 3: sip:outbound.example.com sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=stun sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=stun Consequently, when proxy 2 fails, there will be no "most specific" match for message 35, only least specific ones. The request should go to proxy 3, but the home proxy could equally likely select proxy 1 (which would then perform triangular routing via proxy 2). To have the home proxy favor proxy 3 in this scenario, I believe we need a URI parameter to hold the reg-id, instead of putting it in the user part. If we would then define that flow selection should be performed based on the URI from which the reg-id parameter is stripped, there would be a partly specific match for proxy 3 and failover would work more smoothly Regards, Jeroen ------=_NextPart_000_0021_01C700E5.D32E82E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Erkki,
 
You are right in the sense that *some* = URI=20 parameter is needed to distinguish between cases (1) and (2), but it = needn't be=20 the reg-id. In any case the specification in the current draft won't = work,=20 because the user part needs to be the same for cases (1) and = (2).
 
If we consider it acceptable that high = availability=20 does not work across vendors, then there is no need to standardize on = any=20 particular URI parameter.
 
Regards,
Jeroen
----- Original Message -----
From:=20 Erkki.Koivusalo@nokia.com =
To: jbemmel@zonnet.nl ; jdrosen@cisco.com=20
Sent: Wednesday, November 01, = 2006 1:47=20 PM
Subject: RE: [Sip] mid-dialog = failover:=20 need URI parameter for reg-id to avoidtriangular routing

Hi=20 Jeroen,
 
But=20 when reading the overview of the draft I came to a different = understanding=20 about
the=20 'stickness' that this draft is trying to achieve. In order of = decreasing=20 preference:
 
1. The specific flow used for a dialog as = indicated by=20 the URI parameters added into Record-Route
2.=20 Any flow registered by the UA as indicated by the user part of the URI = as=20 added to Path & S-R
3.=20 Any proxy within the cluster as indicated by the host part of the URI = as in=20 initial REGISTER
 
I=20 did not find reg-id to be significant in any of those three options. = The=20 instance-id (together
with=20 username and the selected proxies for the outbound-proxy-set) is = sufficient to=20 identify
any=20 existing flow (as for item 2).
 
In=20 which use case a proxy should be able to prefer a specific flow with a = specific reg-id ?
I=20 did not find any such use case in the draft.
 
Regards,
 
Erkki
-----Original Message-----
From: ext Jeroen van = Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 01 November, 2006=20 14:02
To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki);=20 jdrosen@cisco.com
Cc: sip@ietf.org
Subject: Re: = [Sip]=20 mid-dialog failover: need URI parameter for reg-id to = avoidtriangular=20 routing

Erkii,
 
The idea is to create 'stickiness', = to prefer=20 using the same flow for all requests unless it fails. So in order of = decreasing preference:
1. Flow with same = reg-id
2. Flow with other = reg-id
3. Flow towards same FQDN (proxy=20 cluster)
 
Note that the matching algorithm I = describe=20 below is incomplete, what is needed is a set of rules that result in = the=20 above order of preference (in other words, binary equality is = insufficient,=20 we need multiple degrees of equality i.e. exact match, partly = specific=20 match, weak match (sam FQDN) and no match)
 
Regards,
Jeroen
----- Original Message ----- =
From:=20 Erkki.Koivusalo@nokia.com=20
To: jbemmel@zonnet.nl ; jdrosen@cisco.com
Sent: Wednesday, November = 01, 2006=20 12:55 PM
Subject: RE: [Sip] = mid-dialog=20 failover: need URI parameter for reg-id to avoidtriangular = routing

Hi,
 
Actually I did not understand why the reg-id should be = encoded into=20 this URI at all.
 
Could you please clarify the reason for its presence ? Or = could the=20 URI be constructed
without the reg-id included to any part of the URI=20 ?
 
Regards,
 
Erkki
-----Original Message-----
From: ext Jeroen = van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 28 October, 2006=20 18:55
To: Jonathan Rosenberg
Cc: sip@ietf.org
Subject: = [Sip]=20 mid-dialog failover: need URI parameter for reg-id to = avoidtriangular=20 routing

Jonathan,
 
Regarding your=20 outbound-discovery-mid-dialog draft: I believe it can work, but = the=20 example given in section 15 has some glitches and may result in=20 sub-optimal routing.
 
The backup flow from the UA x = should have a=20 different reg-id, say reg-id=3D*2* (instead of 1 as per the = example in the=20 draft). Assume there is also a user y registered, via proxy 1 = and proxy=20 3. Then the connection table = at the home=20 proxy would look like
 
TLS connection to = 1:
   =20 sip:outbound.example.com
   =20 = sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun

TLS connection to 2:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun
 
TLS connection to = 3:
   =20 sip:outbound.example.com
   =20 = sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun<= /FONT>
   =20 = sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun=
 
Consequently, when proxy 2 = fails, there=20 will be no "most specific" match for message 35, only least = specific=20 ones. The request should go to proxy 3, but the home proxy could = equally=20 likely select proxy 1 (which would then perform triangular = routing via=20 proxy 2).
 
To have the home proxy favor = proxy 3 in=20 this scenario, I believe we need a URI parameter to hold the = reg-id,=20 instead of putting it in the user part. If we would then define = that=20 flow selection should be performed based on the URI from which = the=20 reg-id parameter is stripped, there would be a partly specific = match for=20 proxy 3 and failover would work more smoothly
 
Regards,
Jeroen
------=_NextPart_000_0021_01C700E5.D32E82E0-- --===============0428504089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0428504089==-- From sip-bounces@ietf.org Sun Nov 05 11:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggkdx-00061q-O2; Sun, 05 Nov 2006 11:14:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggkdw-00060m-Ji for sip@ietf.org; Sun, 05 Nov 2006 11:14:44 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggkdv-0004cG-AN for sip@ietf.org; Sun, 05 Nov 2006 11:14:44 -0500 Received: from [192.168.2.102] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA5FHkjp003625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Nov 2006 09:17:47 -0600 In-Reply-To: <003c01c6ff74$b86ae420$800101df@acmepacket.com> References: <032401c6fecf$b1fa15c0$640fa8c0@cis.neustar.com><706DA215-450D-4AFD-82E2-1679B33EF943@softarmor.com><454B719E.6000507@cisco.com><4FEB9119-4FFF-4F6F-900E-8D45FED3931A@softarmor.com> <454B772E.7030303@cisco.com> <003c01c6ff74$b86ae420$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D5493E2-3FEA-4A98-A190-2EC47367F36B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Sun, 5 Nov 2006 10:14:05 -0600 To: Bob Penfield X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'IETF SIP List' , 'Paul Kyzivat' , Michael Thomas , "'Elwell, John'" , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 3, 2006, at 12:20 PM, Bob Penfield wrote: > > The PSTN circuit switched world has physical security. Its users > have some assurance that the "bits" of their phone call are > delivered intact and only those with access to and control of the > switching equipment could see or muck with those bits. In the > packet world, we must use TLS to provide the same assurance because > things in the clear can be seen and mucked by anybody with a > computer. With TLS, only those with access to or control of the > intermediaries (proxies, B2BUA, SBCs, etc) can see or muck with the > signaling "bits". We have the a similar sort of transitive trust, > although in the wide open Internet we may have not have the pre- > established relationships between providers as exists in the PSTN. > Ah, speaking as a former recreational (okay, SOMETIMES I got paid for it. That make me a pro?) hacker of the phone system, I have to say "Nope. It's just that the PSTN has a better press bureau". For example, the way ISDN is generally deployed in the US, anybody can present any caller-ID number that they ant to deploy. And anybody who can drop an inductive pickup (or even a couple of alligator clips) on your line gets your signaling AND your media in the clear. And bored technicians sitting in LD-carrier switching junctions listen in on 1-900-calls (US sexy-chat services) with amazing frequency. Actually, they frequently step through entire banks of circuits sampling calls just to make sure things are working ok. Maybe they don't listen much, but they could if they wanted to. > The requirement for sips is at a minimum is to provide that level > of security. Its not to equal a military secure phone. That's the > next level of security that needs to be worked on. You mean, "none, why bother?" -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 11:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgkhL-0007wn-9Y; Sun, 05 Nov 2006 11:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgkhK-0007wh-4k for sip@ietf.org; Sun, 05 Nov 2006 11:18:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgkhI-00056B-RS for sip@ietf.org; Sun, 05 Nov 2006 11:18:14 -0500 Received: from [192.168.2.102] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA5FLf8N003631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Nov 2006 09:21:45 -0600 In-Reply-To: <454BF20C.20608@cisco.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com> <454BF20C.20608@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 10:18:00 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 3, 2006, at 7:51 PM, Jonathan Rosenberg wrote: > > The oft-cited problem is one of performance for real-time services, > i.e., the delays in call setup that tcp would cause. I'm not enough > of a TCP expert to know whether any of these have merit or are just > bogus paranoia. > I believe that particular argument is bogus, at least within the bounds of IMS as currently defined. Since the TCP connection to the P- CSCF would be formed during registration, there should generally be no impact on call-setup times. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 11:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglDK-0007sx-KE; Sun, 05 Nov 2006 11:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglDJ-0007sr-BQ for sip@ietf.org; Sun, 05 Nov 2006 11:51:17 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglDB-00015U-TB for sip@ietf.org; Sun, 05 Nov 2006 11:51:17 -0500 Received: (qmail 27010 invoked by uid 0); 5 Nov 2006 16:52:17 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Nov 2006 16:52:17 -0000 Message-ID: <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" , "Jonathan Rosenberg" References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com><45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com><454BF20C.20608@cisco.com> <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 17:51:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Your mileage may vary here. In the best case TCP will be at par with UDP. You need a connection between each pair of hops, so for a typical case (see e.g. http://www.tech-invite.com/Ti-ims-sesflow-1.html) that's 6 + 1 (because the I-CSCF drops out) = 7 connections. Even when assuming outbound on both sides, the worst case still involves 5 TCP setups (sequentially). That being said, the way things are going those INVITEs will quickly reach the 1300 byte limit (if not at the UA then somewhere at one of the proxies, see message 1f). So assuming IETF recommendations are followed, UDP won't be a feasible option for long. Regards, jeroen Dean Willis wrote: > On Nov 3, 2006, at 7:51 PM, Jonathan Rosenberg wrote: > >> >> The oft-cited problem is one of performance for real-time services, >> i.e., the delays in call setup that tcp would cause. I'm not enough >> of a TCP expert to know whether any of these have merit or are just >> bogus paranoia. >> > > I believe that particular argument is bogus, at least within the > bounds of IMS as currently defined. Since the TCP connection to the P- > CSCF would be formed during registration, there should generally be > no impact on call-setup times. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 11:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglJ8-0001zD-1G; Sun, 05 Nov 2006 11:57:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglJ6-0001z1-8p for sip@ietf.org; Sun, 05 Nov 2006 11:57:16 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglJ3-0001bS-Vd for sip@ietf.org; Sun, 05 Nov 2006 11:57:16 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 11:57:13 -0500 Received: from 10.128.41.8 ([10.128.41.8]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 5 Nov 2006 16:57:12 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 05 Nov 2006 10:00:05 -0500 From: Eric Burger To: Dean Willis Message-ID: Thread-Topic: On Trial Balloon (on sips) Thread-Index: AccA6xOhUhg3wmzeEduSmQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Nov 2006 16:57:13.0768 (UTC) FILETIME=[711A2A80:01C700FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: SIP List Subject: [Sip] On Trial Balloon (on sips) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sitting back for the past two weeks and getting immense enjoyment (and insomnia relief) from the sips: discussion, here are my consolidated thoughts and recommendation. THOUGHTS ======== 1. sips: really, really was meant to be "Require: TLS" (Especially given the *suggestion* that all sip connections be over TLS, if possible.) 2. Unsolvable problems are unsolvable (Does the PSTN gateway send a call directly to a phone, which results in the same *expectation* of security for Joe Average caller, or does the gateway send a call to another gateway into SIP-land, in which case Joe Average caller wanted their call to proceed with TLS? In the latter case, there is no way to signal Joe's desire, nor a way to signal failure. That problem is not solvable.) 3. Francois was tasked with editing a document offering a BCP on sips:, not tasked with fixing sips:. 4. Joe Average user *does* assign meaning to meaningless protocol tokens, even if he is dead wrong (Domain names are opaque, meaningless strings that translate to IP addresses that are almost as meaningless. However, people really do expect cantata.com to refer to Cantata Technology.) 5. Just because something is broken and old does NOT mean we should hack around it. I know I am being less than practical here, but the IETF really should do the right thing and fix mistakes. We should NOT become 3GPP and say, "We had no clue 6 years ago how to do it, so we guessed. We guessed wrong, and even though no one has implementations yet, since we wrote it down and ratified it, there is no way we could possibly do the right thing." 6. Experience from messaging world: We *learned* from the disaster that was https and went with explicit link security requests. In other words, SAY WHAT YOU MEAN. By the way, it makes DNS easier, especially if the target of a sip: request and sips: request is always going to be the same. 7. Experience from messaging world: If something isn't ironclad clear why one needs to implement security, it won't happen. If one should use TLS, unless one feels one does not need to, one does not implement it. (Why spend more on hardware and software for encryption and compression if I don't have to? I get way more calls/server if I don't use TLS. I can then tell my customer that sips doesn't do anything for them anyway, because it is trying to solve an unsolvable problem. Thus I get sales because I am cheaper than the competition. Competition sees this and follows suit. Any surprise why sips isn't one of the more implemented features?) RECOMMENDATION ============== BCP should simply state "sips is hopelessly broken and meaningless. Will be replaced by more robust mechanism in future. Until then, if you want to support, for example, secure SIMPLE, it might be useful to implement it." All of the gateway discussion, rather than being important for a BCP, actually is critical for explaining why sips is hopelessly broken. We can split hairs as to whether gateways are in or out for the discussion, or how many gatewayed-to protocols can dance on the head of a pin, but that really does NOT get us closer to the important point of letting the world know the reality of the meaning of sips (why we would publish ANYTHING now) or to a better solution. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 12:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglQ2-0006W3-4a; Sun, 05 Nov 2006 12:04:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglQ0-0006Vy-BF for sip@ietf.org; Sun, 05 Nov 2006 12:04:24 -0500 Received: from [130.129.67.127] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglPz-0002Jv-1U for sip@ietf.org; Sun, 05 Nov 2006 12:04:24 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 6E2E01CC61; Sun, 5 Nov 2006 09:04:04 -0800 (PST) To: Eric Burger Subject: Re: [Sip] On Trial Balloon (on sips) References: From: EKR Date: Sun, 05 Nov 2006 09:04:04 -0800 In-Reply-To: (Eric Burger's message of "Sun, 05 Nov 2006 10:00:05 -0500") Message-ID: <86odrln7uj.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger writes: > 6. Experience from messaging world: We *learned* from the disaster > that was https and went with explicit link security requests. In > other words, SAY WHAT YOU MEAN. By the way, it makes DNS easier, > especially if the target of a sip: request and sips: request is > always going to be the same. Sorry, what is the claim from the "messaging world" that https was a disaster? "Big fat success" would have been the word I would have used. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 12:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglU5-0000FW-KL; Sun, 05 Nov 2006 12:08:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglU3-0000Cw-Qe for sip@ietf.org; Sun, 05 Nov 2006 12:08:35 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglU2-0002vC-Js for sip@ietf.org; Sun, 05 Nov 2006 12:08:35 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 12:08:34 -0500 Received: from 10.128.41.8 ([10.128.41.8]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 5 Nov 2006 17:08:33 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 05 Nov 2006 12:08:31 -0500 Subject: Re: [Sip] On Trial Balloon (on sips) From: Eric Burger To: EKR Message-ID: Thread-Topic: [Sip] On Trial Balloon (on sips) Thread-Index: AccA/Hf+W2UO2r87SeuXLloMUWjqQQAAIzFV In-Reply-To: <86odrln7uj.fsf@delta.rtfm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 05 Nov 2006 17:08:34.0600 (UTC) FILETIME=[06E8E280:01C700FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Looking at it from a user=B9s perspective, https is extremely successful. Poor choice of words on my part. The problem is confusing an application request for security services with = a transport indication of security services. We now have a plethora of port numbers and URI schemes to simply have an application request, "be secure, now." That is the disaster, not the user-visible feature. Sorry that I wa= s not clear in the post. See IMAP's or SUBMIT's approach to the problem of offering insecure and secure services over the same protocol. On 11/5/06 12:04 PM, "EKR" wrote: > Eric Burger writes: >> 6. Experience from messaging world: We *learned* from the disaster >> that was https and went with explicit link security requests. In >> other words, SAY WHAT YOU MEAN. By the way, it makes DNS easier, >> especially if the target of a sip: request and sips: request is >> always going to be the same. >=20 > Sorry, what is the claim from the "messaging world" that https was > a disaster? "Big fat success" would have been the word I would have > used. >=20 > -Ekr >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 12:28:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglkE-00006j-0d; Sun, 05 Nov 2006 12:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglkC-0008Vi-MR for sip@ietf.org; Sun, 05 Nov 2006 12:25:16 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglkB-000529-4R for sip@ietf.org; Sun, 05 Nov 2006 12:25:16 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA5HP9RQ015721 for ; Sun, 5 Nov 2006 19:25:14 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 19:25:13 +0200 Received: from [10.162.253.213] ([10.162.253.213]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 5 Nov 2006 19:25:12 +0200 Message-ID: <454E1E69.6050703@nokia.com> Date: Sun, 05 Nov 2006 09:24:57 -0800 From: Aki Niemi Organization: Nokia-NRC/Helsinki User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: IETF SIP List X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2006 17:25:13.0816 (UTC) FILETIME=[5A7D2580:01C700FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] Updated draft-niemi-sip-subnot-etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hodwy, Managed to squeeze in an update to the conditional subscribe draft: http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt Major changes include: - Bunch of clarifications and fixes contributed by Johnny Vrancken - Added the concept of "*" entity-tag, as suggested by Christian Schmidt The rationale for the latter change is that it turns out if you're suppressing NOTIFYs within the subscription, it doesn't matter what the actual value of the entity-tag is; the superfluous notifications should simply get suppressed by default. It is now possible by including Suppress-Notify-If-Match: * to the SUBSCRIBE in subscription refreshes/unsubscribes. This has some other interesting uses as well, like being able to do a HEAD like query for the current entity-tag, or a heartbeat-type function to check the liveliness of a resource (without the extra cost of receiving the notification). In essence, the client need not bother tracking the etags unless it is resuming a subscription, or using polling to query the state. To me, this is a simple addition that doesn't introduce any complexity, and ought to be the default behavior anyway. I'm planning to make a fairly extensive rewrite of this draft to make it look more like an implementation spec, including adding detailed examples and moving some of the requirements text to an appendix. However, before I commit to that, it would be nice to get some traction to the draft from the working group. Is this something the SIP WG is interested in progressing as a WG effort? Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 12:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gglmh-0004CL-Ma; Sun, 05 Nov 2006 12:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gglmg-00048F-Dq for sip@ietf.org; Sun, 05 Nov 2006 12:27:50 -0500 Received: from [130.129.67.127] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gglme-0005Nc-48 for sip@ietf.org; Sun, 05 Nov 2006 12:27:50 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id AE76D1CC61; Sun, 5 Nov 2006 09:27:33 -0800 (PST) To: Eric Burger Subject: Re: [Sip] On Trial Balloon (on sips) References: From: EKR Date: Sun, 05 Nov 2006 09:27:33 -0800 In-Reply-To: (Eric Burger's message of "Sun, 05 Nov 2006 12:08:31 -0500") Message-ID: <86veltls6y.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger writes: > Looking at it from a user=B9s perspective, https is extremely successfu= l. > Poor choice of words on my part. > > The problem is confusing an application request for security services w= ith a > transport indication of security services. We now have a plethora of p= ort > numbers and URI schemes to simply have an application request, "be secu= re, > now." That is the disaster, not the user-visible feature. Sorry that = I was > not clear in the post. Sorry, I don't see why this is a particular problem, outside of religion about conserving ports. > See IMAP's or SUBMIT's approach to the problem of offering insecure and > secure services over the same protocol. Funny, when *I* use IMAP/TLS, I use it over a separate port. So, let's take a step back. There are three properties you'd like to be a= ble to have (defined for the moment over point-to-point connections): 1. The ability to have a reference that when dereferenced you are guarant= eed to get a secure connection. 2. The ability for the server to demux secure and insecure connections. 3. The ability to provide "best-effort" or "opportunistic" security where the peers jointly determine that they support security. So, https: is about (1). Separate ports is about (2). There's no reason why you can't provide protocols where there's a separate URI scheme but that share a port for TLS and regular protocol traffic. You just need some way to demux SSL versus not. In the case of HTTP, the Netscape guys decided it was easiest on a different port (note that S-HTTP used the same port). Obviously, if you want (3) you need to run over the same port (e.g., RFC 2817), but there's also often a need to ensure downgrade (see 1). -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 13:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgmtJ-0006zp-Vj; Sun, 05 Nov 2006 13:38:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgmtJ-0006zk-CG for sip@ietf.org; Sun, 05 Nov 2006 13:38:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgmtE-0001Gw-18 for sip@ietf.org; Sun, 05 Nov 2006 13:38:45 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2006 10:38:39 -0800 X-IronPort-AV: i="4.09,389,1157353200"; d="scan'208"; a="85835370:sNHT52541793" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA5IcdL7022236; Sun, 5 Nov 2006 10:38:39 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA5IcaAo019607; Sun, 5 Nov 2006 10:38:36 -0800 (PST) Received: from [130.129.69.123] (sjc-vpn7-591.cisco.com [10.21.146.79]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA5IPTCJ018494; Sun, 5 Nov 2006 10:25:29 -0800 In-Reply-To: <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com><45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com><454BF20C.20608@cisco.com> <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 13:38:28 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1798; t=1162751919; x=1163615919; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20SIP=20as=20an=20alternative=20to=20IKE?, =20was=3A=20Re=3A=20[Sip ]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DKsGWkppFmA8KiJRO82zucRvaJT4=3D; b=Bds8mtGBiuAPzqyJ3H8fgukvdGJifd1rRzRu0mR5TQzWIeRvNC1olFLMCS4ltshE87rk55eG xKaZLfTNnqU3b5cA/8PD6t2YUKE2AJWGUD0XVauDulPrS4w+thkg4QdJ; X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 5, 2006, at 11:51 AM, Jeroen van Bemmel wrote: > Dean, > > Your mileage may vary here. In the best case TCP will be at par > with UDP. You need a connection between each pair of hops, so for a > typical case (see e.g. http://www.tech-invite.com/Ti-ims- > sesflow-1.html) that's 6 + 1 (because the I-CSCF drops out) = 7 > connections. Even when assuming outbound on both sides, the worst > case still involves 5 TCP setups (sequentially). > That's one way of looking at it. The other way is to ask why there are 7 hops in the first place! > That being said, the way things are going those INVITEs will > quickly reach the 1300 byte limit (if not at the UA then somewhere > at one of the proxies, see message 1f). So assuming IETF > recommendations are followed, UDP won't be a feasible option for long. > > Regards, > jeroen > > > Dean Willis wrote: >> On Nov 3, 2006, at 7:51 PM, Jonathan Rosenberg wrote: >> >>> >>> The oft-cited problem is one of performance for real-time services, >>> i.e., the delays in call setup that tcp would cause. I'm not enough >>> of a TCP expert to know whether any of these have merit or are just >>> bogus paranoia. >>> >> >> I believe that particular argument is bogus, at least within the >> bounds of IMS as currently defined. Since the TCP connection to >> the P- >> CSCF would be formed during registration, there should generally be >> no impact on call-setup times. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 13:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggn0X-0001M0-7w; Sun, 05 Nov 2006 13:46:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggn0W-0001L2-5S for sip@ietf.org; Sun, 05 Nov 2006 13:46:12 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggn0T-0001si-Qj for sip@ietf.org; Sun, 05 Nov 2006 13:46:12 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA5Icc803096; Sun, 5 Nov 2006 13:38:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 12:45:31 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C416@zrc2hxm2.corp.nortel.com> In-Reply-To: <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Thread-Index: AccA9jU5dgdK94joTkyPQ/RtUqOioQAElQOA From: "Samir Srivastava" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Joel M. Halpern" , IETF SIP List , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I too believe so. Proxies in the path mostly will keep the TCP connections persistent between them and we are talking about connect-reuse. If the UAC and UAS are only reachable via UDP, then it will be only two TCP connection setup delay. But I don't believe so as SDP is becoming huge and huge, these two TCP connection setup will be far better than the call failure due to loss of packets etc... How long people will keep refraining from using Security, unless it doesn't come with prohibiting price ? Also with Proxy-Require (TCP), we know that it is e2e TCP, Do we need then PRACK ? We can simplify the complex state m/c.... Offer / Answer break ? Thx Samir >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: Sunday, November 05, 2006 8:18 AM >To: Jonathan Rosenberg >Cc: Joel M. Halpern; 'IETF SIP List'; Aki Niemi >Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE:=20 >TLS meaning > > >On Nov 3, 2006, at 7:51 PM, Jonathan Rosenberg wrote: > >> >> The oft-cited problem is one of performance for real-time services,=20 >> i.e., the delays in call setup that tcp would cause. I'm not=20 >enough of=20 >> a TCP expert to know whether any of these have merit or are=20 >just bogus=20 >> paranoia. >> > >I believe that particular argument is bogus, at least within=20 >the bounds of IMS as currently defined. Since the TCP=20 >connection to the P- CSCF would be formed during registration,=20 >there should generally be no impact on call-setup times. > >-- >Dean > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomY-0005FI-U6; Sun, 05 Nov 2006 15:39:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomW-0005Ev-SW for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgomT-0006IZ-FE for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJa008217; Sun, 5 Nov 2006 14:39:47 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:41 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Date: Sun, 5 Nov 2006 21:39:38 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B272@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Thread-Index: Acb735DO2hLdDQoLSyisDLk4w7jBbgABPjwwAC9h5DABEXRlMA== From: "Drage, Keith \(Keith\)" To: , X-OriginalArrivalTime: 05 Nov 2006 20:39:38.0538 (UTC) FILETIME=[833478A0:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As individual) I had a brief look at this draft. It would seem to me that proxies could be considered in networks as two forms: - As edge proxies, where we have the only mechanism of routeing to or from the user. - As "routeing" proxies, where the aim is to provide connectivity from one SIP proxy to another. For the first set, I think you need to provide some discussion in your draft of why outbound does not support your needs, i.e. what capabilities you do not get from outbound but which you do get from your proposals. For the second set, we would seem to be straying into the overall area that touches congestion control (where out of service is an extreme form of congestion). I would like to see some discussion of how this does not or does relate to the mechanisms being discussed in SIPPING to support congestion control. Finally you have plumped straight away for a new method and header in SIP. Why is it appropriate to use SIP to do this rather than some other protocol running between the two entities? I think you should also consider addressing this document to SIPPING, and concentrating foremost on the requirements you need to fulfil rather than the protocol solution. Regards Keith > -----Original Message----- > From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com]=20 > Sent: 31 October 2006 04:15 > To: sip@ietf.org > Subject: FW: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > Fwding the mail to the list. > I did a reply , should have done reply all. >=20 > Thanks Dale for pointing this. >=20 > -Sreeram. >=20 > -----Original Message----- > From: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks) > Sent: Monday, October 30, 2006 11:21 AM > To: 'Dale.Worley@comcast.net' > Subject: RE: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > Hi Dale, >=20 > There are 2 Cases > Proxy with backup: Means there is inactive unit. Which will=20 > take over when the active proxy is taken out (Duplex) >=20 > Proxy without backup: These are proxies which work as stand-alone. > Proxies to be stand alone are generally very rare in field=20 > but can be possible. >=20 > When we say a Proxy with out backup giving the alternative ip=20 > address is the case when standalone proxy (P1) is giving the=20 > details of proxy P2 . >=20 > The use cases have shown some of these cases. >=20 > We will take care that the sentence is reformatted in the=20 > next release to make it clear. >=20 > Regards, > Sreeram >=20 >=20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Monday, October 30, 2006 10:19 AM > To: sip@ietf.org > Subject: Re: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > You write: >=20 > Similarly, on restart/disconnect of a SIP entity without=20 > backup, the > same problem exists and there is no way by which SIP entity that is > restarting/disconnecting can inform about the alternative=20 > IP address > (if available) to other SIP entities to which it can communicate so > that graceful handling of existing sessions (or calls) or future > sessions can be performed using alternate IP address. >=20 > I don't understand what the "alternate IP address" can be --=20 > you've already said the SIP entity does not have a backup, so=20 > there can be no alternate IP address at which to contact the backup. >=20 > Dale >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomZ-0005FP-Ia; Sun, 05 Nov 2006 15:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomX-0005F0-9O; Sun, 05 Nov 2006 15:39:53 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgomV-0006J7-Uf; Sun, 05 Nov 2006 15:39:53 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJg008217; Sun, 5 Nov 2006 14:39:50 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:44 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 5 Nov 2006 21:39:39 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B275@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 Thread-Index: Acb9HMGYbN03Kru0Txm7A8W6sKmaHAD05pNg From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 05 Nov 2006 20:39:40.0242 (UTC) FILETIME=[84387B20:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: SIP WG , Gonzalo Camarillo Subject: [Sip] RE: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Can someone clarify for me the current status of NACK in regard to SigComp. This draft seems to imply that it is mandatory in some form but I don't remember any statement in other ROHC documents implying that it is anything other than just another optional extension. Can someone point me at some words. Regards Keith > -----Original Message----- > From: cco [mailto:cristian.constantin@iptel.org]=20 > Sent: 31 October 2006 18:45 > To: 'rohc@ietf.org' > Cc: Gonzalo Camarillo; SIP WG; Drage, Keith (Keith); Dean Willis > Subject: Re: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 >=20 > On Tue, Oct 31, 2006 at 10:04:49AM -0600, Adam Roach wrote: > > I have been asked to perform a dedicated review on the document=20 > > draft-ietf-rohc-sigcomp-sip-03. My comments follow. Note=20 > that I have=20 > > implemented this specification, any many of my comments arise from=20 > > issues I identified during such implementation. > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > I'm having a lot of difficulty parsing the final paragraph=20 > in section > > 3.2: > >=20 > > Compressors that make use of initial state memory MUST=20 > implement the > > SigComp Negative Acknowledgement (NACK) Mechanism=20 > [RFC4077]. (Note > > that there is no such requirement on decompressors, but see also > > Section 6.) For this requirement, initial state memory=20 > is defined as > > the assumption of a non-zero SMS value before having received an > > advertisement of non-zero SMS (e.g., via returned parameters as > > specified in section 9.4.9 of [RFC3320]); ANY/SigComp as=20 > defined in > > [RFC3320] does not have initial state memory. >=20 > cristian: and this gets even more confusing since at 3.4 we can read: >=20 > 3.4. SigComp_version (SV) for SIP/SigComp >=20 > For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. >=20 > For SIP/SigComp: >=3D 0x02 (at least SigComp + NACK) > >=20 > >=20 > > There are two separate points of confusion for me: > >=20 > > 1. I don't understand the assertion that decompressors=20 > don't need to > > implement RFC 4077. Decompressors serve the critical role of > > generating NACK messages when decompression fails.=20 > (And, in fact, > > text at the end of section 6.3 implies that NACK=20 > implementation is > > required in decompressors as well). > >=20 > > 2. The document has already established that stateless compression > > (i.e., compression that doesn't take advantage of initial state > > memory) is pointless for SIP endpoints -- so the clause > > "Compressors that make use of initial state memory" pretty much > > collapses to just "Compressors." > >=20 > > So, unless I've missed something, this paragraph should be=20 > rewritten as: > >=20 > > SIP/SigComp endpoints MUST implement the SigComp Negative > > Acknowledgement (NACK) Mechanism [RFC4077]. >=20 > cristian: I think this should clear everything up; and there=20 > should be no doubts on whether NACK should be used or not. >=20 > since you have already mentioned sipit, here is the=20 > experience I have gained from the sigcomp testing done at the=20 > last one:=20 > clients that use dynamic compression but do not impl. NACK=20 > _cannot_ recover from compartment/state mismanagement (which=20 > can happen for various reasons either at the proxy or at the=20 > client side); clients that implement NACK _do_ recover. >=20 > bye now! > cristian >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomY-0005FI-U6; Sun, 05 Nov 2006 15:39:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomW-0005Ev-SW for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgomT-0006IZ-FE for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJa008217; Sun, 5 Nov 2006 14:39:47 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:41 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Date: Sun, 5 Nov 2006 21:39:38 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B272@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Thread-Index: Acb735DO2hLdDQoLSyisDLk4w7jBbgABPjwwAC9h5DABEXRlMA== From: "Drage, Keith \(Keith\)" To: , X-OriginalArrivalTime: 05 Nov 2006 20:39:38.0538 (UTC) FILETIME=[833478A0:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As individual) I had a brief look at this draft. It would seem to me that proxies could be considered in networks as two forms: - As edge proxies, where we have the only mechanism of routeing to or from the user. - As "routeing" proxies, where the aim is to provide connectivity from one SIP proxy to another. For the first set, I think you need to provide some discussion in your draft of why outbound does not support your needs, i.e. what capabilities you do not get from outbound but which you do get from your proposals. For the second set, we would seem to be straying into the overall area that touches congestion control (where out of service is an extreme form of congestion). I would like to see some discussion of how this does not or does relate to the mechanisms being discussed in SIPPING to support congestion control. Finally you have plumped straight away for a new method and header in SIP. Why is it appropriate to use SIP to do this rather than some other protocol running between the two entities? I think you should also consider addressing this document to SIPPING, and concentrating foremost on the requirements you need to fulfil rather than the protocol solution. Regards Keith > -----Original Message----- > From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com]=20 > Sent: 31 October 2006 04:15 > To: sip@ietf.org > Subject: FW: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > Fwding the mail to the list. > I did a reply , should have done reply all. >=20 > Thanks Dale for pointing this. >=20 > -Sreeram. >=20 > -----Original Message----- > From: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks) > Sent: Monday, October 30, 2006 11:21 AM > To: 'Dale.Worley@comcast.net' > Subject: RE: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > Hi Dale, >=20 > There are 2 Cases > Proxy with backup: Means there is inactive unit. Which will=20 > take over when the active proxy is taken out (Duplex) >=20 > Proxy without backup: These are proxies which work as stand-alone. > Proxies to be stand alone are generally very rare in field=20 > but can be possible. >=20 > When we say a Proxy with out backup giving the alternative ip=20 > address is the case when standalone proxy (P1) is giving the=20 > details of proxy P2 . >=20 > The use cases have shown some of these cases. >=20 > We will take care that the sentence is reformatted in the=20 > next release to make it clear. >=20 > Regards, > Sreeram >=20 >=20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Monday, October 30, 2006 10:19 AM > To: sip@ietf.org > Subject: Re: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > You write: >=20 > Similarly, on restart/disconnect of a SIP entity without=20 > backup, the > same problem exists and there is no way by which SIP entity that is > restarting/disconnecting can inform about the alternative=20 > IP address > (if available) to other SIP entities to which it can communicate so > that graceful handling of existing sessions (or calls) or future > sessions can be performed using alternate IP address. >=20 > I don't understand what the "alternate IP address" can be --=20 > you've already said the SIP entity does not have a backup, so=20 > there can be no alternate IP address at which to contact the backup. >=20 > Dale >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomZ-0005FP-Ia; Sun, 05 Nov 2006 15:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomX-0005F0-9O; Sun, 05 Nov 2006 15:39:53 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgomV-0006J7-Uf; Sun, 05 Nov 2006 15:39:53 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJg008217; Sun, 5 Nov 2006 14:39:50 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:44 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 5 Nov 2006 21:39:39 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B275@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 Thread-Index: Acb9HMGYbN03Kru0Txm7A8W6sKmaHAD05pNg From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 05 Nov 2006 20:39:40.0242 (UTC) FILETIME=[84387B20:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: SIP WG , Gonzalo Camarillo Subject: [Sip] RE: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Can someone clarify for me the current status of NACK in regard to SigComp. This draft seems to imply that it is mandatory in some form but I don't remember any statement in other ROHC documents implying that it is anything other than just another optional extension. Can someone point me at some words. Regards Keith > -----Original Message----- > From: cco [mailto:cristian.constantin@iptel.org]=20 > Sent: 31 October 2006 18:45 > To: 'rohc@ietf.org' > Cc: Gonzalo Camarillo; SIP WG; Drage, Keith (Keith); Dean Willis > Subject: Re: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 >=20 > On Tue, Oct 31, 2006 at 10:04:49AM -0600, Adam Roach wrote: > > I have been asked to perform a dedicated review on the document=20 > > draft-ietf-rohc-sigcomp-sip-03. My comments follow. Note=20 > that I have=20 > > implemented this specification, any many of my comments arise from=20 > > issues I identified during such implementation. > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > I'm having a lot of difficulty parsing the final paragraph=20 > in section > > 3.2: > >=20 > > Compressors that make use of initial state memory MUST=20 > implement the > > SigComp Negative Acknowledgement (NACK) Mechanism=20 > [RFC4077]. (Note > > that there is no such requirement on decompressors, but see also > > Section 6.) For this requirement, initial state memory=20 > is defined as > > the assumption of a non-zero SMS value before having received an > > advertisement of non-zero SMS (e.g., via returned parameters as > > specified in section 9.4.9 of [RFC3320]); ANY/SigComp as=20 > defined in > > [RFC3320] does not have initial state memory. >=20 > cristian: and this gets even more confusing since at 3.4 we can read: >=20 > 3.4. SigComp_version (SV) for SIP/SigComp >=20 > For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. >=20 > For SIP/SigComp: >=3D 0x02 (at least SigComp + NACK) > >=20 > >=20 > > There are two separate points of confusion for me: > >=20 > > 1. I don't understand the assertion that decompressors=20 > don't need to > > implement RFC 4077. Decompressors serve the critical role of > > generating NACK messages when decompression fails.=20 > (And, in fact, > > text at the end of section 6.3 implies that NACK=20 > implementation is > > required in decompressors as well). > >=20 > > 2. The document has already established that stateless compression > > (i.e., compression that doesn't take advantage of initial state > > memory) is pointless for SIP endpoints -- so the clause > > "Compressors that make use of initial state memory" pretty much > > collapses to just "Compressors." > >=20 > > So, unless I've missed something, this paragraph should be=20 > rewritten as: > >=20 > > SIP/SigComp endpoints MUST implement the SigComp Negative > > Acknowledgement (NACK) Mechanism [RFC4077]. >=20 > cristian: I think this should clear everything up; and there=20 > should be no doubts on whether NACK should be used or not. >=20 > since you have already mentioned sipit, here is the=20 > experience I have gained from the sigcomp testing done at the=20 > last one:=20 > clients that use dynamic compression but do not impl. NACK=20 > _cannot_ recover from compartment/state mismanagement (which=20 > can happen for various reasons either at the proxy or at the=20 > client side); clients that implement NACK _do_ recover. >=20 > bye now! > cristian >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggomh-0005HT-GR; Sun, 05 Nov 2006 15:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggomf-0005H0-9T for sip@ietf.org; Sun, 05 Nov 2006 15:40:01 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggomd-0006L5-So for sip@ietf.org; Sun, 05 Nov 2006 15:40:01 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJm008217; Sun, 5 Nov 2006 14:39:59 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:40 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:37 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 21:39:37 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B271@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAF+HWyAASB9O4AEZXjUw From: "Drage, Keith \(Keith\)" To: "Samir Srivastava" , "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 05 Nov 2006 20:39:37.0929 (UTC) FILETIME=[82D78B90:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I assume you mean you dissented at the meeting itself? I don't remember (and cannot find) any response to the minutes not being an accurarate record of what we decided, or any specific comment by you on list objecting to the contents of the minutes. Whereever we are on that, I will say is that we work to rough consensus, not absolute consensus, taking into account both the discussions on the mailing list and in the meeting. It is very, very clear that at the moment that we need to do lots more work, and the INFORMATIONAL document being progressed by Francois is the way to do that. At the end of that work we will then judge consensus on what way forward we should go. So I will stress that the discussion now is not about expressing opinions. It is about capturing technical input in the INFORMATIONAL document that can be used for the WG making decisions on sound technical grounds on what needs to change. Regards Keith > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com]=20 > Sent: 31 October 2006 01:16 > To: Drage, Keith (Keith); Francois Audet; IETF SIP List > Subject: RE: [Sip] RE: TLS meaning >=20 > Thx Keith.=20 >=20 > With due respect to chairs decision, I dissented at the=20 > meeting minutes itself. I who suggested the=20 > Proxy-Require/Require was told in the ad-hoc meeting that=20 > there is already consensus on the SIPS and it is not even on=20 > the agenda to discuss. I was not the part of the meeting=20 > where that discussion was done. >=20 > BTW, I am eagerly waiting for the contents requested in 3.C ) .=20 >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Sunday, October 29, 2006 3:50 PM > > To: Audet, Francois (SC100:3055); IETF SIP List > > Subject: RE: [Sip] RE: TLS meaning > >=20 > > As WG chair: > >=20 > > Please bear in mind: > >=20 > > 1) The WG agreed at the last meeting that the scope of this > > document is an informational document. The minutes clearly=20 > state this,=20 > > and the charter as follows: > >=20 > > Mar 2007 Guidelines for use of SIP security to WGLC=20 > (Informational) > >=20 > > Jun 2007 Guidelines for use of SIP security to IESG=20 > (Informational) > >=20 > > Was updated to say this. (Both these have been presented to the > mailing > > list without comment in reasonable time so this as far as I am > concerned > > is a decision. Therefore this document in itself does not deprecate=20 > > SIPS, and we will need to decide to do this later. > >=20 > > 2) This document does not update RFC 3261 it itself. Francois > > please update your abstract because this is not what this document > does. > > You may also want to investigate the RFC 2119 language as a result. > > There will have to be other documents that update RFC3261=20 > that are not=20 > > this document. Note that we did agree that this document=20 > was the basis=20 > > of this work, and therefore it should be reissued as a -00 SIP WG=20 > > document. > >=20 > > 3) What this document is/was intended to do was: > >=20 > > - clearly document what we had now, i.e. identify what occurred if > > the user attempted xyd, and what level of security they did get if > they > > attempted xyz. > >=20 > > - identify what improvements or changes to our current SIP > > security, as defined in RFC 3261, where therefore required. These > could > > fall into the following: > >=20 > > A) creation of new mechanisms that provided a level of security > > that is not provided by the existing mechanisms. I this case we need > to > > clearly identify the improvement and motivate why it is needed. > >=20 > > B) changes to existing mechanisms to make them work. In this case, > > we need to clearly state why the existing mechanism is broken, i.e. > not > > interoperable to produce a deterministic result. > >=20 > > C) deprecation of existing mechanism - the one we seem to be > > discussing here. In this case, I (and we are the ones that have to=20 > > justify this to the IESG) want to understand firstly why=20 > the existing=20 > > mechanism is harmful to implementations if it continues to=20 > exist, and=20 > > also understand the impact on the existing implementation=20 > community if=20 > > we do deprecate. Therefore what this discussion must do is identify=20 > > these reasons and put them in the document. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 27 October 2006 17:12 > > > To: IETF SIP List > > > Subject: RE: [Sip] RE: TLS meaning > > > > > > In case people having noticed, it is looking like we are having a=20 > > > mailing list hum on the following 2 questions: > > > > > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) > > > > > > 2 - Do you favour getting rid of the last-hop-exception rule > (yes/no) > > > > > > > > > Note: Voting Yes on 2 does not necessarily imply you are=20 > voting No=20 > > > on 1, but it will only make sense if sips is not > deprecated. > > > > > > I'm keeping track of the vote. > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomX-0005F8-W0; Sun, 05 Nov 2006 15:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomW-0005Eq-Qx for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgomT-0006Ia-FG for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJc008217; Sun, 5 Nov 2006 14:39:47 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:42 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Re: What consensus? Date: Sun, 5 Nov 2006 21:39:40 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B276@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: What consensus? Thread-Index: Acb9OMuJgwZPG9S/QYCs7eRpZPh/TwDuCCKQ From: "Drage, Keith \(Keith\)" To: "Joel M. Halpern" , "IETF SIP List" X-OriginalArrivalTime: 05 Nov 2006 20:39:40.0850 (UTC) FILETIME=[84954120:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The second function of the document is to identify decisions that need to be made, and to explain the technical pros and cons of choosing one solution or another in any particular decision. The function of the document is not to make those decisions. The WG will make those decisions based on the content of this document. Regards Keith > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: 31 October 2006 22:04 > To: IETF SIP List > Subject: RE: [Sip] Re: What consensus? >=20 > Just to be clear, for the work item which says "document 3261=20 > SIPS as defined, I believe Francois is correct, and I believe=20 > (if I have understood everything I have read properly) that=20 > his description is accurate. The fact that many people don't=20 > like it is irrelevant to that question. It is what it is. >=20 > My concern is that the chartered work also includes making=20 > recommendations for where we should go. > That is what I have been arguing on. >=20 > At 12:48 PM 10/31/2006, Francois Audet wrote: > >SHORT TERM: > > > >- We need to put a lid on inflated expectations of what SIPS really=20 > >means. > > I favor a minimalistic interpretation of what SIPS means. The=20 > >sooner we > > close that lid, the sooner we can move on to the LONG TERM. > > > >- This interpretation is in line with the spirit of RFC 3261. We are > > trying first to "explain" RFC 3261, with it's=20 > limitations, in order=20 > >to > > > > move on to something more comprehensive. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggomh-0005HT-GR; Sun, 05 Nov 2006 15:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggomf-0005H0-9T for sip@ietf.org; Sun, 05 Nov 2006 15:40:01 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggomd-0006L5-So for sip@ietf.org; Sun, 05 Nov 2006 15:40:01 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJm008217; Sun, 5 Nov 2006 14:39:59 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:40 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:37 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 21:39:37 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B271@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAF+HWyAASB9O4AEZXjUw From: "Drage, Keith \(Keith\)" To: "Samir Srivastava" , "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 05 Nov 2006 20:39:37.0929 (UTC) FILETIME=[82D78B90:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I assume you mean you dissented at the meeting itself? I don't remember (and cannot find) any response to the minutes not being an accurarate record of what we decided, or any specific comment by you on list objecting to the contents of the minutes. Whereever we are on that, I will say is that we work to rough consensus, not absolute consensus, taking into account both the discussions on the mailing list and in the meeting. It is very, very clear that at the moment that we need to do lots more work, and the INFORMATIONAL document being progressed by Francois is the way to do that. At the end of that work we will then judge consensus on what way forward we should go. So I will stress that the discussion now is not about expressing opinions. It is about capturing technical input in the INFORMATIONAL document that can be used for the WG making decisions on sound technical grounds on what needs to change. Regards Keith > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com]=20 > Sent: 31 October 2006 01:16 > To: Drage, Keith (Keith); Francois Audet; IETF SIP List > Subject: RE: [Sip] RE: TLS meaning >=20 > Thx Keith.=20 >=20 > With due respect to chairs decision, I dissented at the=20 > meeting minutes itself. I who suggested the=20 > Proxy-Require/Require was told in the ad-hoc meeting that=20 > there is already consensus on the SIPS and it is not even on=20 > the agenda to discuss. I was not the part of the meeting=20 > where that discussion was done. >=20 > BTW, I am eagerly waiting for the contents requested in 3.C ) .=20 >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Sunday, October 29, 2006 3:50 PM > > To: Audet, Francois (SC100:3055); IETF SIP List > > Subject: RE: [Sip] RE: TLS meaning > >=20 > > As WG chair: > >=20 > > Please bear in mind: > >=20 > > 1) The WG agreed at the last meeting that the scope of this > > document is an informational document. The minutes clearly=20 > state this,=20 > > and the charter as follows: > >=20 > > Mar 2007 Guidelines for use of SIP security to WGLC=20 > (Informational) > >=20 > > Jun 2007 Guidelines for use of SIP security to IESG=20 > (Informational) > >=20 > > Was updated to say this. (Both these have been presented to the > mailing > > list without comment in reasonable time so this as far as I am > concerned > > is a decision. Therefore this document in itself does not deprecate=20 > > SIPS, and we will need to decide to do this later. > >=20 > > 2) This document does not update RFC 3261 it itself. Francois > > please update your abstract because this is not what this document > does. > > You may also want to investigate the RFC 2119 language as a result. > > There will have to be other documents that update RFC3261=20 > that are not=20 > > this document. Note that we did agree that this document=20 > was the basis=20 > > of this work, and therefore it should be reissued as a -00 SIP WG=20 > > document. > >=20 > > 3) What this document is/was intended to do was: > >=20 > > - clearly document what we had now, i.e. identify what occurred if > > the user attempted xyd, and what level of security they did get if > they > > attempted xyz. > >=20 > > - identify what improvements or changes to our current SIP > > security, as defined in RFC 3261, where therefore required. These > could > > fall into the following: > >=20 > > A) creation of new mechanisms that provided a level of security > > that is not provided by the existing mechanisms. I this case we need > to > > clearly identify the improvement and motivate why it is needed. > >=20 > > B) changes to existing mechanisms to make them work. In this case, > > we need to clearly state why the existing mechanism is broken, i.e. > not > > interoperable to produce a deterministic result. > >=20 > > C) deprecation of existing mechanism - the one we seem to be > > discussing here. In this case, I (and we are the ones that have to=20 > > justify this to the IESG) want to understand firstly why=20 > the existing=20 > > mechanism is harmful to implementations if it continues to=20 > exist, and=20 > > also understand the impact on the existing implementation=20 > community if=20 > > we do deprecate. Therefore what this discussion must do is identify=20 > > these reasons and put them in the document. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 27 October 2006 17:12 > > > To: IETF SIP List > > > Subject: RE: [Sip] RE: TLS meaning > > > > > > In case people having noticed, it is looking like we are having a=20 > > > mailing list hum on the following 2 questions: > > > > > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) > > > > > > 2 - Do you favour getting rid of the last-hop-exception rule > (yes/no) > > > > > > > > > Note: Voting Yes on 2 does not necessarily imply you are=20 > voting No=20 > > > on 1, but it will only make sense if sips is not > deprecated. > > > > > > I'm keeping track of the vote. > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomX-0005F8-W0; Sun, 05 Nov 2006 15:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgomW-0005Eq-Qx for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgomT-0006Ia-FG for sip@ietf.org; Sun, 05 Nov 2006 15:39:52 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA5KdcJc008217; Sun, 5 Nov 2006 14:39:47 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 14:39:42 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Nov 2006 21:39:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Re: What consensus? Date: Sun, 5 Nov 2006 21:39:40 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B276@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: What consensus? Thread-Index: Acb9OMuJgwZPG9S/QYCs7eRpZPh/TwDuCCKQ From: "Drage, Keith \(Keith\)" To: "Joel M. Halpern" , "IETF SIP List" X-OriginalArrivalTime: 05 Nov 2006 20:39:40.0850 (UTC) FILETIME=[84954120:01C7011A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The second function of the document is to identify decisions that need to be made, and to explain the technical pros and cons of choosing one solution or another in any particular decision. The function of the document is not to make those decisions. The WG will make those decisions based on the content of this document. Regards Keith > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: 31 October 2006 22:04 > To: IETF SIP List > Subject: RE: [Sip] Re: What consensus? >=20 > Just to be clear, for the work item which says "document 3261=20 > SIPS as defined, I believe Francois is correct, and I believe=20 > (if I have understood everything I have read properly) that=20 > his description is accurate. The fact that many people don't=20 > like it is irrelevant to that question. It is what it is. >=20 > My concern is that the chartered work also includes making=20 > recommendations for where we should go. > That is what I have been arguing on. >=20 > At 12:48 PM 10/31/2006, Francois Audet wrote: > >SHORT TERM: > > > >- We need to put a lid on inflated expectations of what SIPS really=20 > >means. > > I favor a minimalistic interpretation of what SIPS means. The=20 > >sooner we > > close that lid, the sooner we can move on to the LONG TERM. > > > >- This interpretation is in line with the spirit of RFC 3261. We are > > trying first to "explain" RFC 3261, with it's=20 > limitations, in order=20 > >to > > > > move on to something more comprehensive. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 15:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgowF-0004rU-Ha; Sun, 05 Nov 2006 15:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfzfk-00076z-1k for sip@ietf.org; Fri, 03 Nov 2006 09:05:28 -0500 Received: from mailway13.teles.de ([195.4.13.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfzdY-0000aO-GZ for sip@ietf.org; Fri, 03 Nov 2006 09:03:16 -0500 Received: by mailway13.teles.de (Postfix, from userid 1000) id 978C45094B; Fri, 3 Nov 2006 15:03:09 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.3-gr0 (2006-06-01) on teles-gw.teles.de X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.3-gr0 Received: from backmex.teles.de (backmex.teles.de [172.20.0.19]) by mailway13.teles.de (Postfix) with ESMTP id 35DEC5092E for ; Fri, 3 Nov 2006 15:03:05 +0100 (CET) Received: by backmex.teles.de with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Nov 2006 15:02:48 +0100 Message-ID: From: Ingo Franz To: sip@ietf.org Date: Fri, 3 Nov 2006 15:03:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sun, 05 Nov 2006 15:49:53 -0500 Subject: [Sip] SIP-COMMON-MIB X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear SIP work group, I'm on the way to implement the SIP-COMMON-MIB module (i know it is not ready yet but hopefully small changes will apear). I wonder about referencing the "SipTCMethodName" type as index in "sipCommonMethodStatsTable","sipCommonStatsRetryTable" and "sipCommonStatusCodeTable". maybe the sipCommonMethodSupportedIndex should be used there or is this OCTET-STRING to use as an index? sorry for my unkownness, thx and best regards ingo franz [*****]TELES AG R&D Postfach 11 07 60 D-10837 Berlin fon: (+49) 30-399 28 1645 fax: (+49) 30-399 28 01 e-mail: i.franz@teles.de _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 16:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgpnR-0004UZ-Kb; Sun, 05 Nov 2006 16:44:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgpnP-0004U7-Mb for sip@ietf.org; Sun, 05 Nov 2006 16:44:51 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgpnN-0006OD-9k for sip@ietf.org; Sun, 05 Nov 2006 16:44:51 -0500 Received: (qmail 3925 invoked by uid 0); 5 Nov 2006 21:44:31 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Nov 2006 21:44:31 -0000 Message-ID: <082a01c70123$9996aba0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Eric Burger" , "Dean Willis" References: Subject: Re: [Sip] On Trial Balloon (on sips) Date: Sun, 5 Nov 2006 22:44:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > THOUGHTS > ======== > > 1. sips: really, really was meant to be "Require: TLS" > (Especially given the *suggestion* that all sip connections > be over TLS, if possible.) > I think you mean "Proxy-Require: TLS" "sips:" was originally meant as "SIP over TLS", in line with HTTP over TLS (RFC2818). The latter does not even contain the word "proxy", but its companion document, RFC2817, does. RFC2817 defines 2 mechanisms related to https: that have so far not been translated to SIP: 1) The "CONNECT" method, to setup a tunnel via a proxy 2) The "Upgrade" header, to request upgrading a TCP connection to TLS (hop-by-hop) I believe in particular (1) is what some people are implicitly asking for, as it reduces the role of proxies as men-in-the-middle and makes the TLS connection end-to-end. (2) was an attempt to get rid of the different ports for http and https (apparently, "At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated.", long before RFC3261...). Perhaps these 2 mechanisms (1 more than 2), and an additional "Proxy-Require" mechanism to get "sips-or-die" forwarding behavior, would be a good supplement to the current arsenal? Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 17:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggquf-0001iI-Uo; Sun, 05 Nov 2006 17:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggque-0001iD-Mb for sip@ietf.org; Sun, 05 Nov 2006 17:56:24 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggquc-0006Gq-Vd for sip@ietf.org; Sun, 05 Nov 2006 17:56:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kA5MuL47136994 for ; Sun, 5 Nov 2006 22:56:21 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA5MxEWA3141780 for ; Sun, 5 Nov 2006 23:59:23 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA5Mu2wT014503 for ; Sun, 5 Nov 2006 23:56:02 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA5Mu2tF014354; Sun, 5 Nov 2006 23:56:02 +0100 In-Reply-To: <454E1E69.6050703@nokia.com> To: Aki Niemi MIME-Version: 1.0 Subject: Re: [Sip] Updated draft-niemi-sip-subnot-etags X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Mon, 6 Nov 2006 00:58:42 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 06/11/2006 00:59:03, Serialize complete at 06/11/2006 00:59:03 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0210402347==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0210402347== Content-Type: multipart/alternative; boundary="=_alternative 007DF61EC225721D_=" This is a multipart message in MIME format. --=_alternative 007DF61EC225721D_= Content-Type: text/plain; charset="US-ASCII" I really think that this is a simple and important optimization and we need to adopt this as WG item. --Avshalom Aki Niemi 05/11/2006 19:24 To IETF SIP List cc Subject [Sip] Updated draft-niemi-sip-subnot-etags Hodwy, Managed to squeeze in an update to the conditional subscribe draft: http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt Major changes include: - Bunch of clarifications and fixes contributed by Johnny Vrancken - Added the concept of "*" entity-tag, as suggested by Christian Schmidt The rationale for the latter change is that it turns out if you're suppressing NOTIFYs within the subscription, it doesn't matter what the actual value of the entity-tag is; the superfluous notifications should simply get suppressed by default. It is now possible by including Suppress-Notify-If-Match: * to the SUBSCRIBE in subscription refreshes/unsubscribes. This has some other interesting uses as well, like being able to do a HEAD like query for the current entity-tag, or a heartbeat-type function to check the liveliness of a resource (without the extra cost of receiving the notification). In essence, the client need not bother tracking the etags unless it is resuming a subscription, or using polling to query the state. To me, this is a simple addition that doesn't introduce any complexity, and ought to be the default behavior anyway. I'm planning to make a fairly extensive rewrite of this draft to make it look more like an implementation spec, including adding detailed examples and moving some of the requirements text to an appendix. However, before I commit to that, it would be nice to get some traction to the draft from the working group. Is this something the SIP WG is interested in progressing as a WG effort? Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 007DF61EC225721D_= Content-Type: text/html; charset="US-ASCII"
I really think that this is a simple and important optimization and we
need to adopt this as WG item.

--Avshalom


Aki Niemi <aki.niemi@nokia.com>

05/11/2006 19:24

To
IETF SIP List <sip@ietf.org>
cc
Subject
[Sip] Updated draft-niemi-sip-subnot-etags





Hodwy,

Managed to squeeze in an update to the conditional subscribe draft:

http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt

Major changes include:

- Bunch of clarifications and fixes contributed by Johnny Vrancken

- Added the concept of "*" entity-tag, as suggested by Christian Schmidt

The rationale for the latter change is that it turns out if you're
suppressing NOTIFYs within the subscription, it doesn't matter what the
actual value of the entity-tag is; the superfluous notifications should
simply get suppressed by default. It is now possible by including

  Suppress-Notify-If-Match: *

to the SUBSCRIBE in subscription refreshes/unsubscribes. This has some
other interesting uses as well, like being able to do a HEAD like query
for the current entity-tag, or a heartbeat-type function to check the
liveliness of a resource (without the extra cost of receiving the
notification).

In essence, the client need not bother tracking the etags unless it is
resuming a subscription, or using polling to query the state. To me,
this is a simple addition that doesn't introduce any complexity, and
ought to be the default behavior anyway.

I'm planning to make a fairly extensive rewrite of this draft to make it
look more like an implementation spec, including adding detailed
examples and moving some of the requirements text to an appendix.

However, before I commit to that, it would be nice to get some traction
to the draft from the working group.

Is this something the SIP WG is interested in progressing as a WG effort?

Cheers,
Aki

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 007DF61EC225721D_=-- --===============0210402347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0210402347==-- From sip-bounces@ietf.org Sun Nov 05 18:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgroD-0006qG-K2; Sun, 05 Nov 2006 18:53:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgroA-0006pw-HW; Sun, 05 Nov 2006 18:53:46 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggro6-0005Nj-S9; Sun, 05 Nov 2006 18:53:46 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 552CA184; Mon, 6 Nov 2006 00:53:42 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 00:53:40 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 00:53:40 +0100 Received: from [131.160.126.72] (rvi2-126-72.lmf.ericsson.se [131.160.126.72]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 56DCE2372; Mon, 6 Nov 2006 01:53:39 +0200 (EET) Message-ID: <454E7982.7000001@ericsson.com> Date: Mon, 06 Nov 2006 01:53:38 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE2918072B275@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918072B275@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2006 23:53:40.0574 (UTC) FILETIME=[9E662FE0:01C70135] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP WG , rohc@ietf.org Subject: [Sip] Re: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, NACK support will be mandatory. Cheers, Gonzalo Drage, Keith (Keith) wrote: > Can someone clarify for me the current status of NACK in regard to > SigComp. > > This draft seems to imply that it is mandatory in some form but I don't > remember any statement in other ROHC documents implying that it is > anything other than just another optional extension. > > Can someone point me at some words. > > Regards > > Keith > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 20:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggsnt-0002dD-I9; Sun, 05 Nov 2006 19:57:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggsns-0002Zi-4U for sip@ietf.org; Sun, 05 Nov 2006 19:57:32 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggsnm-0005Ob-Mi for sip@ietf.org; Sun, 05 Nov 2006 19:57:32 -0500 Received: from [130.129.71.98] ([130.129.71.98]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA60vK631488; Sun, 5 Nov 2006 17:57:20 -0700 Message-ID: <454E886E.8020401@ntt-at.com> Date: Sun, 05 Nov 2006 16:57:18 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt References: <5D1A7985295922448D5550C94DE291806E0863@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291806E0863@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I generally agree with Jonathan here. I don't think we should produce a document per error. Rather, can't we take an approach that we are considering for the hitch-hiker's guide? Where a single document will be updated at certain frequency. I think from the people looking for these information it is important that one can find all the errors and potential fixes in one place. Another approach is to have the document produced in the way it is mentioned in the draft but have another document that references all the fixes in a similar fashion that hitch-hiker's guide does for all the core-SIP related RFC/drafts. Regards Shida Drage, Keith (Keith) wrote: > Thanks for the comments. > > Inline below: > > Regards > > Keith > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 01 November 2006 22:02 >> To: Drage, Keith (Keith) >> Cc: SIP >> Subject: Re: [Sip] Request for views on >> draft-drage-sip-essential-correction-00.txt >> >> Keith, >> >> I agree with the final step here, but I'm not so sure about >> your details of the intermediate steps. >> >> In particular, I think it is too onerous to require one I-D >> per issue. >> FOr example it would be nice for someone to go through the >> bugzilla database and submit one I-D with all of the things >> in it that we need to put into the corrections spec. THis is >> more palatable than having to submit 30 separate documents, >> each 6 pages in length (5.5 pages overhead and 1/2 page for >> the useful content). >> > > I think flexibility is needed here. Grouping of related issues, are a > number of well understood and non-controversial (but otherwise > essential) corrections is probably OK. > > What we don't want to do is group things that require lots of discussion > time in the WG (SIPS fixes?) with those that don't. Nor do we want to > present two issues together such that one confuses the understanding and > WG discussion of the other. > >> Also we need to discuss what happens when more bugs get >> reported after the correction RFC is published. DO we revise >> that RFC? Or issue another corrections document? >> >> > The idea was that the reader only need read the original RFC plus 1 > correction RFC. Thus as more corrections are discovered, we take the > contents of the original correction RFC, the new fixes, and produce a > new RFC that obsoletes the first correction RFC, but which still updates > the original RFC. Remember however that the draft replacement correction > RFC can still be rapidly put together - and it only needs IESG review > and approval, as all the individual components have been WGLC > separately. Therefore I see this process as being reasonably quick (in > IETF terms). > > Note that in terms of the normal RFC process we would lose the > correction RFC if we ever take any SIP documents from proposed standard > to draft standard, i.e. the proposed standard RFC would obsolete the > > >> -Jonathan R. >> >> Drage, Keith (Keith) wrote: >> >> >>> I have recently submitted >>> >>> >>> >> http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correcti >> >>> on >>> -00.txt >>> >>> The idea behind this draft, is to put some management into getting >>> real >>> bugfixes: >>> >>> - into one place where people can find it >>> - give it standards track RFC status so that people know they have >>> to implement it. >>> >>> If people not already consulted have views on this process, then >>> please let them be known. >>> >>> The idea would be to start this process (taking into >>> >> account any input >> >>> from the WG) after the next IETF meeting. >>> >>> Regards >>> >>> Keith >>> >>> Keith Drage >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >>> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 05 23:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgvhK-0000Wx-39; Sun, 05 Nov 2006 23:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgvhJ-0000Wi-4a for sip@ietf.org; Sun, 05 Nov 2006 23:02:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgvhE-00023y-Nv for sip@ietf.org; Sun, 05 Nov 2006 23:02:57 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2006 20:02:46 -0800 X-IronPort-AV: i="4.09,389,1157353200"; d="scan'208"; a="339748276:sNHT55893536" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA642khX023192; Sun, 5 Nov 2006 20:02:46 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA642abF013584; Sun, 5 Nov 2006 20:02:36 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 20:02:36 -0800 Received: from [10.21.153.160] ([10.21.153.160]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 20:02:35 -0800 Message-ID: <454EB3DA.9040707@cisco.com> Date: Sun, 05 Nov 2006 23:02:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com><45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com><454BF20C.20608@cisco.com> <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> In-Reply-To: <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 04:02:35.0666 (UTC) FILETIME=[64685F20:01C70158] DKIM-Signature: a=rsa-sha1; q=dns; l=2114; t=1162785766; x=1163649766; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20SIP=20as=20an=20alternative=20to=20IKE?, =20was=3A=20Re=3A=20[Sip ]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D3J6z4rL5qqQYx1diYUYECqYHZiw=3D; b=OWq4gfHCQn6ErMTrmEMIpg23G8fSNVV0nYhZ8RcYB2591kUO8MSte21eD+tMwuixK6vCeP8R 4ne8/XS/g8V8VJhvCFtje4rPCZuylkEApMW/1EQzSV2jneWNoHrC0nIL; Authentication-Results: sj-dkim-5.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Dean, > > Your mileage may vary here. In the best case TCP will be at par with > UDP. You need a connection between each pair of hops, so for a typical > case (see e.g. http://www.tech-invite.com/Ti-ims-sesflow-1.html) that's > 6 + 1 (because the I-CSCF drops out) = 7 connections. Even when assuming > outbound on both sides, the worst case still involves 5 TCP setups > (sequentially). That would be a very unlikely worst case. In general all of those connections, except perhaps the first and the last, will typically be up all the time. And if outbound was used for IMS then the first and the last would also be up all the time the UAs are able. Its possible that some freakish set of circumstances could conspire to result in needing 5 sequential setups, but such a case is likely to be in calamitous situations. Paul > That being said, the way things are going those INVITEs will quickly > reach the 1300 byte limit (if not at the UA then somewhere at one of the > proxies, see message 1f). So assuming IETF recommendations are followed, > UDP won't be a feasible option for long. > > Regards, > jeroen > > > Dean Willis wrote: >> On Nov 3, 2006, at 7:51 PM, Jonathan Rosenberg wrote: >> >>> >>> The oft-cited problem is one of performance for real-time services, >>> i.e., the delays in call setup that tcp would cause. I'm not enough >>> of a TCP expert to know whether any of these have merit or are just >>> bogus paranoia. >>> >> >> I believe that particular argument is bogus, at least within the >> bounds of IMS as currently defined. Since the TCP connection to the P- >> CSCF would be formed during registration, there should generally be >> no impact on call-setup times. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 00:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgxJK-00072T-Gs; Mon, 06 Nov 2006 00:46:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgxJJ-00072O-Lq for sip@ietf.org; Mon, 06 Nov 2006 00:46:17 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgxJH-00041u-Aw for sip@ietf.org; Mon, 06 Nov 2006 00:46:17 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA65cfk06850 for ; Mon, 6 Nov 2006 00:38:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: TLS meaning Date: Sun, 5 Nov 2006 23:45:31 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C544@zrc2hxm2.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918072B271@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAF+HWyAASB9O4AEZXjUwAB6EbkA= From: "Samir Srivastava" To: "Drage, Keith \(Keith\)" , "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I dissented at the minutes of meetings which were emailed on the response of Mat. Refer http://www1.ietf.org/mail-archive/web/sip/current/msg16008.html Personally I agreed to contribute with the text in Francois's document, why SIPS is broken. In the meeting on the slides of cipher-suites, there was a question "Should we clean up the mess of SIPS" and I was told by everybody that we had CONSENSUS on keeping SIPS. There was nothing for me to say on that. Anyway people know it is broken within the time. Thx Samir >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 >Sent: Sunday, November 05, 2006 12:40 PM >To: Srivastava, Samir (SC100:8826); Audet, Francois=20 >(SC100:3055); IETF SIP List >Subject: RE: [Sip] RE: TLS meaning > >I assume you mean you dissented at the meeting itself? > >I don't remember (and cannot find) any response to the minutes=20 >not being an accurarate record of what we decided, or any=20 >specific comment by you on list objecting to the contents of=20 >the minutes. > >Whereever we are on that, I will say is that we work to rough=20 >consensus, not absolute consensus, taking into account both=20 >the discussions on the mailing list and in the meeting. > >It is very, very clear that at the moment that we need to do=20 >lots more work, and the INFORMATIONAL document being=20 >progressed by Francois is the way to do that. At the end of=20 >that work we will then judge consensus on what way forward we=20 >should go. > >So I will stress that the discussion now is not about=20 >expressing opinions. It is about capturing technical input in=20 >the INFORMATIONAL document that can be used for the WG making=20 >decisions on sound technical grounds on what needs to change. > >Regards > >Keith > >> -----Original Message----- >> From: Samir Srivastava [mailto:samirsr@nortel.com] >> Sent: 31 October 2006 01:16 >> To: Drage, Keith (Keith); Francois Audet; IETF SIP List >> Subject: RE: [Sip] RE: TLS meaning >>=20 >> Thx Keith.=20 >>=20 >> With due respect to chairs decision, I dissented at the meeting=20 >> minutes itself. I who suggested the Proxy-Require/Require=20 >was told in=20 >> the ad-hoc meeting that there is already consensus on the=20 >SIPS and it=20 >> is not even on the agenda to discuss. I was not the part of the=20 >> meeting where that discussion was done. >>=20 >> BTW, I am eagerly waiting for the contents requested in 3.C ) .=20 >>=20 >> Thx >> Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 09:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5eL-00015D-Ex; Mon, 06 Nov 2006 09:40:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5eK-000157-Dl for sip@ietf.org; Mon, 06 Nov 2006 09:40:32 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh5eD-00016V-2F for sip@ietf.org; Mon, 06 Nov 2006 09:40:32 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 1DA636C023; Mon, 6 Nov 2006 09:40:03 -0500 (EST) Subject: RE: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F74C28D@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60F74C28D@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 06 Nov 2006 06:40:11 -0800 Message-Id: <1162824011.3016.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Sat, 2006-11-04 at 01:16 -0600, Samir Srivastava wrote: > Hi Scott, > > Sorry for the delayed response. In line. > > Thx > Samir > > >-----Original Message----- > >From: Scott Lawrence [mailto:slawrence@pingtel.com] > >Sent: Wednesday, October 18, 2006 6:45 AM > >To: Srivastava, Samir (SC100:8826) > >Cc: sip@ietf.org > >Subject: RE: [Sip] I-D on handling large UDP responses > > > >On Mon, 2006-10-16 at 03:25 -0500, Samir Srivastava wrote: > > > >> The proposed mechanism can be used only for REQ/RSP. How can we > >> address the problems caused in 200 OK (Offer) and ACK > >(Answer) due to > >> UDP between some proxies ? In the current model, UAC gets the > >> complete Large 200 OK (with delayed arrival of 140/141 or you change > >> the current solution w.r.t. 140/141), but ACK follows the > >different IP hops etc... > > > >Are you asking how this helps to detect a lost ACK? If so, I > >don't think that it does, but a lost ACK will cause the final > >response to be resent, so you'll know anyway. Eventually the > >14x should arrive, providing a hint as to the possible > >problem. Besides, the only time the ACK is likely to be lost > >due to UDP fragmentation is if it has the SDP answer and is > >itself large, which the sender already knows. > > > > Due to UDP hops etc in between, ACK can be lost... How can you enforce > ACK not to be lost. Then you can either add Proxy-Require in ACK.. But > This will contradict the 3261 > Proxy-Require rule, as ACK should have the same Proxy-Require as that of > INVITE... > In my personal opinion, all this is complex. That's because you're trying to make it solve problems it isn't meant to solve (indeed - it is just meant to diagnose problems, not solve them). > Additional Running code question, how many states it will introduce to > all ready complex state m/c's (170, If I remember correctly are already > there with complete PRACK, UPDATE etc... ) The system sending the large response has no new states - it sends the 141 and forgets about it. A system that receives a 140 or 141 could decide to remember that fact and slow or reduce retries, or change transports, but it's not required to do so. > >> We might be doing congestion handling in SIP for UDP transports in > >> future, where some of it is provided by other transports. In > >my purist > >> mind, SIP messages are becoming huge, so UDP is no more > >relevant. UDP > >> was taken initially, as it was simple to transport short SIP message > >> at that time. > > > >I'm hoping that providing better diagnostics that show how UDP > >fails will cause end users to put pressure on vendors to > >support TCP and/or TLS. > > With Proxy-Require (tcp), providers using only UDP will start loosing > the revenue and will be forced to upgrade. My good wish :-) It doesn't work that way. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 11:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6zD-0006MS-Uc; Mon, 06 Nov 2006 11:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6zB-0006KR-Ls for sip@ietf.org; Mon, 06 Nov 2006 11:06:09 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6pp-0003bu-6o for sip@ietf.org; Mon, 06 Nov 2006 10:56:37 -0500 Received: from [130.129.68.74] ([130.129.68.74]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA6F06TN009012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Nov 2006 09:00:07 -0600 In-Reply-To: <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com><45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com><454BF20C.20608@cisco.com> <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A763EAD-0A39-4FE5-997F-BA3BC2D9C22B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Mon, 6 Nov 2006 09:56:20 -0600 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 5, 2006, at 10:51 AM, Jeroen van Bemmel wrote: > Dean, > > Your mileage may vary here. In the best case TCP will be at par > with UDP. You need a connection between each pair of hops, so for a > typical case (see e.g. http://www.tech-invite.com/Ti-ims- > sesflow-1.html) that's 6 + 1 (because the I-CSCF drops out) = 7 > connections. Even when assuming outbound on both sides, the worst > case still involves 5 TCP setups (sequentially). > > That being said, the way things are going those INVITEs will > quickly reach the 1300 byte limit (if not at the UA then somewhere > at one of the proxies, see message 1f). So assuming IETF > recommendations are followed, UDP won't be a feasible option for long. > > Regards, > jeroen Perhaps, but the argument was that TCP was unsuitable for mobile use because of the unsuitability of TCP on the last-hop mobile phone link. I think we now have ample evidence to refute that part of the argument. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 11:13:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh74P-0008CB-Ok; Mon, 06 Nov 2006 11:11:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh74O-0008C5-Tg for sip@ietf.org; Mon, 06 Nov 2006 11:11:32 -0500 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh74I-0006BR-5U for sip@ietf.org; Mon, 06 Nov 2006 11:11:32 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id E5DB820A2E7 for ; Mon, 6 Nov 2006 17:11:23 +0100 (CET) Message-Id: <7.0.1.0.0.20061106163258.028a5188@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Nov 2006 16:34:38 +0100 To: sip@ietf.org From: Jiri Kuthan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] FYI: new SER is out X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FYI: a new version of SER, open source SIP proxy implementation, has been released. For more details see http://lists.iptel.org/pipermail/serusers/2006-November/031223.html -jiri -- 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 sip-bounces@ietf.org Mon Nov 06 11:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7jU-0002fO-S7; Mon, 06 Nov 2006 11:54:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7jS-0002as-Te for sip@ietf.org; Mon, 06 Nov 2006 11:53:58 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7jO-0002aj-5X for sip@ietf.org; Mon, 06 Nov 2006 11:53:58 -0500 Received: from [130.129.67.54] (dhcp67-54.ietf67.org [130.129.67.54]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kA6GrbwX003441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 10:53:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <454E6189.1020002@nostrum.com> Date: Sun, 05 Nov 2006 16:11:21 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Rohan Mahy , SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.67.54 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Sip] Outbound and SigComp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan: After reading through the new section in outbound relating to SigComp (section 8.2), I have two small comments. The first is that STUN messages don't have any way to convey SigComp compartment information. This is almost certainly okay, since the document says to carry them using the "well known shim header," which doesn't result in any attempt to create state. To avoid confusion, you should add a paragraph to the end of the section reading something like: Because the bytecodes expressed in the well-known shim header do not store any state, correlation of such SigComp requests to a compartment is not necessary. To avoid ambiguity, we add the following requirement: any SigComp state that may result from a message that, once decompressed, turns out to be a STUN message, MUST be discarded. Also, you cite the shim as coming from RFC 3320. In fact, it comes from the implementors' guide, which in in WGLC: draft-ietf-rohc-sigcomp-impl-guide-08.txt. /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 sip-bounces@ietf.org Mon Nov 06 11:56:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7jO-0002Qq-Sq; Mon, 06 Nov 2006 11:53:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7jN-0002MX-9s for sip@ietf.org; Mon, 06 Nov 2006 11:53:53 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7jF-0002Zt-2b for sip@ietf.org; Mon, 06 Nov 2006 11:53:53 -0500 Received: from [130.129.67.54] (dhcp67-54.ietf67.org [130.129.67.54]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kA6GrRkd003417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 10:53:30 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <454E5CDA.6090207@nostrum.com> Date: Sun, 05 Nov 2006 15:51:22 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo References: <3B670951.93A4D00A@lmf.ericsson.se> In-Reply-To: <3B670951.93A4D00A@lmf.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.67.54 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, adam.roach@ericsson.com, Jonathan Rosemberg Subject: [Sip] Re: 489 status code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On July 31, 2001, Gonzalo Camarillo wrote: > A minor comment about 489 status code: In Adam's event draft it means > "Bad Event", and in Jonathan's early media draft it means "Request > Updated". Since both are just I-Ds this is not really an issue right > now, but when they advance to RFCs we will have to resolve this > conflict. ...and in draft-gurbani-sip-large-udp-response-00, it means "Use Congestion Controlled Transport." I'd offer to move mine somewhere else, but it's been published as an RFC already. /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 sip-bounces@ietf.org Mon Nov 06 12:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7sW-0006kM-Fw; Mon, 06 Nov 2006 12:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7sV-0006kB-Cj for sip@ietf.org; Mon, 06 Nov 2006 12:03:19 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7sP-0003mF-1N for sip@ietf.org; Mon, 06 Nov 2006 12:03:19 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8B0002YJBWI3@siemenscomms.co.uk> for sip@ietf.org; Mon, 06 Nov 2006 17:02:20 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG85WW>; Mon, 06 Nov 2006 17:02:09 +0000 Content-return: allowed Date: Mon, 06 Nov 2006 17:02:02 +0000 From: "Elwell, John" To: Jonathan Rosenberg , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F26670A4B254C@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Sip] Comments on gruu-11 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Major comment: Section 3.2: "Only when the contact expires, either through explicit de-registration or timeout, will all of the temporary GRUUs be invalidated." So how many temporary GRUUs does the domain proxy need to remember? If a UA remains registered for a year, say, and refreshes its registration every hour, say, that is a lot of storage. Minor comments / nits: Section 2: "remote target: The term "remote target" refers to a URI that a user agent uses to identify itself for receipt of both mid-dialog and out-of-dialog requests." This doesn't seem to be consistent with RFC 3261, where a remote target doesn't identify the UA itself, but a remote UA. Section 3: "GRUUs are issued by SIP domains and always route back to a proxy in that domain." This is not always true now that UAs can provide their own URIs with GRUU properties, as described in 3.2. Section 3.4 on dereferencing a GRUU: "Because a GRUU is simply a URI, a UA dereferences it in exactly the same way as it would any other URI. However, once the request has been routed to the appropriate proxy, the behavior is slightly different...." A UA-assigned GRUU will be an exception to the procedures in this paragraph. Section 4.1 on generating a REGISTER request: 'Each such Contact header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header field.' Change "header field" to "header field parameter" or just "parameter". Section 6.1 on request targeting: "If there are no registered contacts bound to the GRUU, the server MUST return a 480." I believe this can apply only to public GRUUs, since temporary GRUUs disappear when registration ceases, so the proxy has no way of knowing whether this was previously a valid temporary GRUU. Hence I would have expected a 404 rather than a 480 response. I think some clarification in the area might be beneficial. Section 6.1 "In many cases, the new request is related to an existing dialog, and may be an attempt to join it (using the Join header field [23]) or replace it (using the Replaces header field [24])." The request could also relate to an existing dialog by means of RFC 4538. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 13:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh99a-00028o-FY; Mon, 06 Nov 2006 13:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh99Z-00028a-BY for sip@ietf.org; Mon, 06 Nov 2006 13:25:01 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh99V-00069C-2d for sip@ietf.org; Mon, 06 Nov 2006 13:25:01 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 10:24:56 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="86224220:sNHT48521403" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6IOu4J007059; Mon, 6 Nov 2006 10:24:56 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6IOuAo028065; Mon, 6 Nov 2006 10:24:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:24:56 -0800 Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:24:56 -0800 Message-ID: <454F7DF7.50702@cisco.com> Date: Mon, 06 Nov 2006 13:24:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670A4B254C@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4B254C@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 18:24:56.0160 (UTC) FILETIME=[DC253600:01C701D0] DKIM-Signature: a=rsa-sha1; q=dns; l=1166; t=1162837496; x=1163701496; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20Comments=20on=20gruu-11; X=v=3Dcisco.com=3B=20h=3DqVM7xt4tXB0j4l3lLS8iT9vkoOc=3D; b=hUNQcRlDhial+GFTRK5aqDW9BGOUdVthN4p8jdy5PafV/mDGzaqKDD8HuyZ1olrqJhfI62Mz BG/vOqzsO3CwPqMyg38HsV3ND1bBi4oqWnSpeoXTtGyrx2m7NnYGxNGJ; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'IETF SIP List' Subject: [Sip] Re: Comments on gruu-11 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One immediate response: Elwell, John wrote: > Jonathan, > > Major comment: > > Section 3.2: "Only when the contact expires, either through explicit > de-registration or timeout, will all of the temporary GRUUs be invalidated." > So how many temporary GRUUs does the domain proxy need to remember? If a UA > remains registered for a year, say, and refreshes its registration every > hour, say, that is a lot of storage. If you choose to implement this by literally storing GRUU, then yes, its a ton. But you wouldn't do that. It is far easier to implement this by constructing them algorithmically. This can be done with no additional storage (there is an algorithm in the annex), and there are several variations that require fixed storage per user (one integer) that can produce much shorter URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 14:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9nh-0000XI-CB; Mon, 06 Nov 2006 14:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9ne-0000UX-TD for sip@ietf.org; Mon, 06 Nov 2006 14:06:26 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9f7-0001Af-46 for sip@ietf.org; Mon, 06 Nov 2006 13:57:38 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 10:57:36 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="86238756:sNHT50593995" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6IvaFv018338; Mon, 6 Nov 2006 10:57:36 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA6IvaW4016863; Mon, 6 Nov 2006 10:57:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:57:36 -0800 Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:57:35 -0800 Message-ID: <454F859F.3080607@cisco.com> Date: Mon, 06 Nov 2006 13:57:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] RE: TLS meaning References: <62B9B0847CC47543B6B3B5E26BD268E60F6875F3@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F6875F3@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 18:57:36.0026 (UTC) FILETIME=[6C5107A0:01C701D5] DKIM-Signature: a=rsa-sha1; q=dns; l=2226; t=1162839456; x=1163703456; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DF7vmGn+0mljziVnIPpUyEGg5x4g=3D; b=BktWYEml+azRbyhVLcDCKofuAI1K3dthtE9I3q/Qm4zJbFew0sOKEfc0lz6Rt5biNSTRRQDJ j4ZuUwlY0NCpRkYWnKPDRz7XBVRGteVURnwGv0uOauzc88hRDw4og1IX; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > Hi Jonathan, > > You have your right to vote and I respect your opinion. > > May I ask following question > > 1) How can I route the non-sip uri over the SIP network. When I need > Proxy-Require for non SIP URI's then why not use the same Proxy-Require > tag for SIP itself. Its a good question; I think the answer depends somewhat on whether these tel URI get quickly translated to sip or whether they hang around (see http://www.ietf.org/internet-drafts/draft-rosenberg-rai-phone-names-numbers-00.txt) I think you would need involvement of Route headers with sips URIs in these cases. > > 2) Without any additional flag for REQUIRE tag, my presence and > reg-info is open to be sent on the unsecure channels to watchers. Why? Use sips URIs for those. > > 3) IMHO, Proxies and routers cannot be compared. Routers only look > into IPAddresses, where Proxies look into the complete SIP message > to,from etc .. Knowing some IP Packets going between two IP address > doesn't reveal much. But knowing To, From etc by any attacker on the > wire does mean much. I don't see how this point is relevant to the discussion. > > 4) SIPS doubles the entries in DNS, registrar etc.. (For SIPS, and > SIP URIS.) Whereas Proxy-Require/Require doesn't require that. True. > > 5) How SIPS will interwork with more workable secure solutions ? With > limited TLS (what it means still open) only, embedded with SIPS how do > you want to upgrade it for DTLS. I am in the camp that views DTLS as equally OK as TLS/TCP. That is, the requirement is on the security mechanism, not the transport protocol. > > 6) If you believe in cipher-suite issue, then Proxy-Require for that > makes SIPS redundant. I do not believe in the need to signal or convey the cipher-suites. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 14:13:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9sc-0002qX-G9; Mon, 06 Nov 2006 14:11:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9sb-0002qS-4C for sip@ietf.org; Mon, 06 Nov 2006 14:11:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9sZ-000302-F0 for sip@ietf.org; Mon, 06 Nov 2006 14:11:33 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 11:11:31 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="86245578:sNHT64211445" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6JBVYI009121; Mon, 6 Nov 2006 11:11:31 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6JBUAo008993; Mon, 6 Nov 2006 11:11:30 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:11:30 -0800 Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:11:30 -0800 Message-ID: <454F88E0.1020108@cisco.com> Date: Mon, 06 Nov 2006 14:11:28 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] RE: TLS meaning References: <5D1A7985295922448D5550C94DE2918072B271@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918072B271@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 19:11:30.0383 (UTC) FILETIME=[5DA1CDF0:01C701D7] DKIM-Signature: a=rsa-sha1; q=dns; l=6981; t=1162840291; x=1163704291; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DF7vmGn+0mljziVnIPpUyEGg5x4g=3D; b=HMTfyUgdAsXH2/uU5bUUPhvo0zTTkp7/d06dao+UrHAMvHf5y6OplVx5vMOYPMsO5g1XPxwn FYIe/mUhQ7cDVD5xjs4p0MAfrQq7FqGmezfaVSJomHG9oGO/xhsog0RC; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One comment here on process. I really don't see the value in an informational document at this point. I'd rather write a draft on what the solution ought to be, whatever that is, and have it be normative. I see little value in producing a document that informationally describes that, just to be followed by yet another which provides the normative version of that. -Jonathan R. Drage, Keith (Keith) wrote: > I assume you mean you dissented at the meeting itself? > > I don't remember (and cannot find) any response to the minutes not being > an accurarate record of what we decided, or any specific comment by you > on list objecting to the contents of the minutes. > > Whereever we are on that, I will say is that we work to rough consensus, > not absolute consensus, taking into account both the discussions on the > mailing list and in the meeting. > > It is very, very clear that at the moment that we need to do lots more > work, and the INFORMATIONAL document being progressed by Francois is the > way to do that. At the end of that work we will then judge consensus on > what way forward we should go. > > So I will stress that the discussion now is not about expressing > opinions. It is about capturing technical input in the INFORMATIONAL > document that can be used for the WG making decisions on sound technical > grounds on what needs to change. > > Regards > > Keith > > >>-----Original Message----- >>From: Samir Srivastava [mailto:samirsr@nortel.com] >>Sent: 31 October 2006 01:16 >>To: Drage, Keith (Keith); Francois Audet; IETF SIP List >>Subject: RE: [Sip] RE: TLS meaning >> >>Thx Keith. >> >>With due respect to chairs decision, I dissented at the >>meeting minutes itself. I who suggested the >>Proxy-Require/Require was told in the ad-hoc meeting that >>there is already consensus on the SIPS and it is not even on >>the agenda to discuss. I was not the part of the meeting >>where that discussion was done. >> >>BTW, I am eagerly waiting for the contents requested in 3.C ) . >> >>Thx >>Samir >> >> >>>-----Original Message----- >>>From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>Sent: Sunday, October 29, 2006 3:50 PM >>>To: Audet, Francois (SC100:3055); IETF SIP List >>>Subject: RE: [Sip] RE: TLS meaning >>> >>>As WG chair: >>> >>>Please bear in mind: >>> >>>1) The WG agreed at the last meeting that the scope of this >>>document is an informational document. The minutes clearly >> >>state this, >> >>>and the charter as follows: >>> >>> Mar 2007 Guidelines for use of SIP security to WGLC >> >>(Informational) >> >>> Jun 2007 Guidelines for use of SIP security to IESG >> >>(Informational) >> >>>Was updated to say this. (Both these have been presented to the >> >>mailing >> >>>list without comment in reasonable time so this as far as I am >> >>concerned >> >>>is a decision. Therefore this document in itself does not deprecate >>>SIPS, and we will need to decide to do this later. >>> >>>2) This document does not update RFC 3261 it itself. Francois >>>please update your abstract because this is not what this document >> >>does. >> >>>You may also want to investigate the RFC 2119 language as a result. >>>There will have to be other documents that update RFC3261 >> >>that are not >> >>>this document. Note that we did agree that this document >> >>was the basis >> >>>of this work, and therefore it should be reissued as a -00 SIP WG >>>document. >>> >>>3) What this document is/was intended to do was: >>> >>>- clearly document what we had now, i.e. identify what occurred if >>>the user attempted xyd, and what level of security they did get if >> >>they >> >>>attempted xyz. >>> >>>- identify what improvements or changes to our current SIP >>>security, as defined in RFC 3261, where therefore required. These >> >>could >> >>>fall into the following: >>> >>>A) creation of new mechanisms that provided a level of security >>>that is not provided by the existing mechanisms. I this case we need >> >>to >> >>>clearly identify the improvement and motivate why it is needed. >>> >>>B) changes to existing mechanisms to make them work. In this case, >>>we need to clearly state why the existing mechanism is broken, i.e. >> >>not >> >>>interoperable to produce a deterministic result. >>> >>>C) deprecation of existing mechanism - the one we seem to be >>>discussing here. In this case, I (and we are the ones that have to >>>justify this to the IESG) want to understand firstly why >> >>the existing >> >>>mechanism is harmful to implementations if it continues to >> >>exist, and >> >>>also understand the impact on the existing implementation >> >>community if >> >>>we do deprecate. Therefore what this discussion must do is identify >>>these reasons and put them in the document. >>> >>>Regards >>> >>>Keith >>> >>> >>>>-----Original Message----- >>>>From: Francois Audet [mailto:audet@nortel.com] >>>>Sent: 27 October 2006 17:12 >>>>To: IETF SIP List >>>>Subject: RE: [Sip] RE: TLS meaning >>>> >>>>In case people having noticed, it is looking like we are having a >>>>mailing list hum on the following 2 questions: >>>> >>>>1 - Do you favour deprecating the sips scheme altogether (yes/no) >>>> >>>>2 - Do you favour getting rid of the last-hop-exception rule >> >>(yes/no) >> >>>> >>>>Note: Voting Yes on 2 does not necessarily imply you are >> >>voting No >> >>>>on 1, but it will only make sense if sips is not >> >>deprecated. >> >>>>I'm keeping track of the vote. >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol Use >>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>sipping@ietf.org for new developments on the application of sip >>>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol Use >>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 15:24:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAxW-0006fM-9x; Mon, 06 Nov 2006 15:20:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAxU-0006al-4U; Mon, 06 Nov 2006 15:20:40 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhAxP-0002Tj-O7; Mon, 06 Nov 2006 15:20:40 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA6KKYL2012749; Mon, 6 Nov 2006 14:20:35 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Nov 2006 14:20:34 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Nov 2006 21:20:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Re: 489 status code Date: Mon, 6 Nov 2006 21:20:26 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B807@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: 489 status code Thread-Index: AccBxIdrtd5YWEX5Rx+kq0PVMLxg1gAG4ihg From: "Drage, Keith \(Keith\)" To: "Adam Roach" X-OriginalArrivalTime: 06 Nov 2006 20:20:27.0873 (UTC) FILETIME=[FFC4AD10:01C701E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, sipping@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG chair) See http://www.iana.org/assignments/sip-parameters for a list of currently assigned response codes (with 489 allocated already as Adam indicates). As definition of a new response code requires a SIP WG document, can I suggest that only such documents make any attempt to assign a response code value - I know this can be useful because the examples have to show it. If your document is not one of these, use 4xx or something else that can be replaced later. I notice also drafts in SIPPING group attempting to assign response codes. Regards Keith =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 November 2006 21:51 > To: Gonzalo Camarillo > Cc: sip@ietf.org; adam.roach@ericsson.com; Jonathan Rosemberg > Subject: [Sip] Re: 489 status code >=20 > On July 31, 2001, Gonzalo Camarillo wrote: > > A minor comment about 489 status code: In Adam's event=20 > draft it means=20 > > "Bad Event", and in Jonathan's early media draft it means "Request=20 > > Updated". Since both are just I-Ds this is not really an=20 > issue right=20 > > now, but when they advance to RFCs we will have to resolve this=20 > > conflict. >=20 > ...and in draft-gurbani-sip-large-udp-response-00, it means=20 > "Use Congestion Controlled Transport." >=20 > I'd offer to move mine somewhere else, but it's been=20 > published as an RFC already. >=20 > /a >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 17:08:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCar-0001a8-Gu; Mon, 06 Nov 2006 17:05:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCap-0001Yg-OD for sip@ietf.org; Mon, 06 Nov 2006 17:05:23 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCak-0002K0-AU for sip@ietf.org; Mon, 06 Nov 2006 17:05:23 -0500 Received: (qmail 26556 invoked by uid 0); 6 Nov 2006 22:04:59 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Nov 2006 22:04:59 -0000 Message-ID: <002901c701ef$9f2a27a0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com><45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com><454BF20C.20608@cisco.com> <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> <7A763EAD-0A39-4FE5-997F-BA3BC2D9C22B@softarmor.com> Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Mon, 6 Nov 2006 23:05:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, I've just done some measurements. This is in no way representative or statistically significant, but what I get on my PDA (Windows Pocket PC 2003) on a commercial Dutch operator GPRS network (no NAT) connecting to my home grown proxy at home (on ADSL and then behind NAT): start-REGISTER-401-REGISTER-OK-end (starting with GPRS off, SIP UA detects IP assignment and registers, times measured at UAC): UDP : 2-3 seconds (T1=2 seconds, no retransmissions occur) TCP: ~1 second connection setup, then 2-3 seconds TLS: ~3 seconds handshake, then 2-3 seconds (without cert checking etc) In all cases, a re-REGISTER sequence has similar timing. In other words: for my environment, once the connection is up, round trip delay differences are indeed negligible Regards, Jeroen Dean Willis wrote: > On Nov 5, 2006, at 10:51 AM, Jeroen van Bemmel wrote: > >> Dean, >> >> Your mileage may vary here. In the best case TCP will be at par >> with UDP. You need a connection between each pair of hops, so for a >> typical case (see e.g. http://www.tech-invite.com/Ti-ims- >> sesflow-1.html) that's 6 + 1 (because the I-CSCF drops out) = 7 >> connections. Even when assuming outbound on both sides, the worst >> case still involves 5 TCP setups (sequentially). >> >> That being said, the way things are going those INVITEs will >> quickly reach the 1300 byte limit (if not at the UA then somewhere >> at one of the proxies, see message 1f). So assuming IETF >> recommendations are followed, UDP won't be a feasible option for >> long. Regards, >> jeroen > > Perhaps, but the argument was that TCP was unsuitable for mobile use > because of the unsuitability of TCP on the last-hop mobile phone > link. I think we now have ample evidence to refute that part of the > argument. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 17:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCnK-0003GD-PO; Mon, 06 Nov 2006 17:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCnI-0003CR-C2 for sip@ietf.org; Mon, 06 Nov 2006 17:18:16 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCnH-0004NE-0i for sip@ietf.org; Mon, 06 Nov 2006 17:18:16 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA6MHg609705; Mon, 6 Nov 2006 17:17:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: TLS meaning Date: Mon, 6 Nov 2006 16:17:24 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F7DBA99@zrc2hxm2.corp.nortel.com> In-Reply-To: <454F859F.3080607@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: AccB1ZDIP6Dt6nIWTiuwYMl6kFTFxwAE4/2g From: "Samir Srivastava" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, in-line. Thx Samir >>=20 >> 1) How can I route the non-sip uri over the SIP network. When I=20 >> need Proxy-Require for non SIP URI's then why not use the same=20 >> Proxy-Require tag for SIP itself. > >Its a good question; I think the answer depends somewhat on=20 >whether these tel URI get quickly translated to sip or whether=20 >they hang around (see >http://www.ietf.org/internet-drafts/draft-rosenberg-rai-phone-n >ames-numbers-00.txt) > >I think you would need involvement of Route headers with sips=20 >URIs in these cases. SS>> I have to take a look on this. >>=20 >> 2) Without any additional flag for REQUIRE tag, my presence and >> reg-info is open to be sent on the unsecure channels to watchers. > >Why? Use sips URIs for those. SS>> As per 3903 PUA PA WATCHER (EPA) (ESC) | | | | | <---- M1: SUBSCRIBE --- | | | | | | ----- M2: 200 OK -----> | | | | | | ----- M3: NOTIFY -----> | | | | | | <---- M4: 200 OK ------ | | | | | | | | ---- M5: PUBLISH ---> | | | | | | <--- M6: 200 OK ---- | | | | | | | ----- M7: NOTIFY -----> | | | | | | <---- M8: 200 OK ------ | If M5 PUBLISH uses the SIPS URI, while in M1 WATCHER uses just the SIP URI. Should we just leave the intermediary to distribute the presence on the unsecure channel. IMHO, PUA should have the control for the security where his presence info is going. Similar for REG-INFO.=20 > >>=20 >> 5) How SIPS will interwork with more workable secure=20 >solutions ? With >> limited TLS (what it means still open) only, embedded with=20 >SIPS how do >> you want to upgrade it for DTLS.=20 > >I am in the camp that views DTLS as equally OK as TLS/TCP.=20 >That is, the=20 >requirement is on the security mechanism, not the transport protocol. > Perfect. I too believe that we should not pose any limit on the secure protocol to be used. I believe in separate header for describing the complete secure protocol properties clearly, instead of embedding them like SIPS means TLS over TCP in 3261. >>=20 >> 6) If you believe in cipher-suite issue, then=20 >Proxy-Require for that >> makes SIPS redundant.=20 > >I do not believe in the need to signal or convey the cipher-suites. NULL encryption ciphers provide no confidentiality. There are some geographic regions where confidentiality is not permitted. (Pl correct me if I am wrong) UAC need to know when his request is not given the desired level of confidentiality. Here we cannot rely on the mandatory ciphers. In this case UAC request should be failed by the proxy with some 4xx, if downstream hop doesn't provide confidentiality. Then UAC may resubmit.=20 There was earlier discussion on Cheater Proxy , Trust and Verify etc for its motivation. Having a well defined mechanism of Secure-Protocol with properties is more future proof. After 3261, we found DTLS now we want to put DTLS. IMHO, similar can be for ciphers.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 18:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQ8-0003T4-Nc; Mon, 06 Nov 2006 17:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQ6-0003R0-JP for sip@ietf.org; Mon, 06 Nov 2006 17:58:22 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDPG-0001BN-73 for sip@ietf.org; Mon, 06 Nov 2006 17:57:31 -0500 Received: from hkaplan [130.129.68.146] by acmepacket.com with ESMTP (SMTPD-9.10) id ADC00630; Mon, 06 Nov 2006 17:57:04 -0500 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] RE: TLS meaning Date: Mon, 6 Nov 2006 17:55:46 -0500 Message-ID: <00b001c701f6$b315c740$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB1ZDIP6Dt6nIWTiuwYMl6kFTFxwAE4/2gAAKewHA= In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F7DBA99@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'IETF SIP List' , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Monday, November 06, 2006 5:17 PM > > >> 2) Without any additional flag for REQUIRE tag, my presence and > >> reg-info is open to be sent on the unsecure channels to watchers. > > > >Why? Use sips URIs for those. > > SS>> As per 3903 > > [snipped diagram] > > If M5 PUBLISH uses the SIPS URI, while in M1 WATCHER uses just the SIP > URI. Should we just leave the intermediary to distribute the presence on > the unsecure channel. IMHO, PUA should have the control for the security > where his presence info is going. Similar for REG-INFO. HK> If you want a UAC to control who gets to see its presence, that should be a package of/within presence, not a URI scheme or require of the subscribe or publish or whatever. The PUBLISH was addressed to the server, and it got there. If you use SIPS it will (hopefully) get there over TLS. > Perfect. I too believe that we should not pose any limit on the secure > protocol to be used. I believe in separate header for describing the > complete secure protocol properties clearly, instead of embedding them > like SIPS means TLS over TCP in 3261. HK> I am in the exact opposite camp. I don't think an application protocol header should specify the transport type at all to be used for forward-routing by other nodes, let alone the intricate details of that transport. Do you expect to specify whether it can be UDP, TCP, or even the MTU as well? :) Encryption mechanisms in particular would be bad for this. There are so many optional/alternate components, that for a UAC to describe all the sets it will "allow" all proxies to use for transporting its message is just not practical. There's a reason negotiation mechanisms exist for encryption protocols, and even with them we have mismatches/failures. SIPS and SIP rely on trusting the proxies in the middle. If you don't trust them there's no point in adding more headers/checks when they can lie about any/all of them. If you DO trust them, then trust them to do the right thing. What they need from the UAC is to know whether the message is sensitive enough that it should not be forwarded if a secure next-hop path is not available. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 18:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDW7-00080q-Qn; Mon, 06 Nov 2006 18:04:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDW5-0007zn-TD for sip@ietf.org; Mon, 06 Nov 2006 18:04:33 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDVw-0002iG-22 for sip@ietf.org; Mon, 06 Nov 2006 18:04:33 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 416745BD; Tue, 7 Nov 2006 00:04:17 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 00:04:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 00:04:17 +0100 Received: from [131.160.126.224] (rvi2-126-224.lmf.ericsson.se [131.160.126.224]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0AC3E2372; Tue, 7 Nov 2006 01:04:15 +0200 (EET) Message-ID: <454FBF6F.4010608@ericsson.com> Date: Tue, 07 Nov 2006 01:04:15 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] Re: 489 status code References: <3B670951.93A4D00A@lmf.ericsson.se> <454E5CDA.6090207@nostrum.com> In-Reply-To: <454E5CDA.6090207@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 23:04:17.0208 (UTC) FILETIME=[E2822B80:01C701F7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, it only took 5 years to get an answer to my email! :o) Thanks for following up ;o) Cheers, Gonzalo Adam Roach wrote: > On July 31, 2001, Gonzalo Camarillo wrote: >> A minor comment about 489 status code: In Adam's event draft it means >> "Bad Event", and in Jonathan's early media draft it means "Request >> Updated". Since both are just I-Ds this is not really an issue right >> now, but when they advance to RFCs we will have to resolve this >> conflict. > > ...and in draft-gurbani-sip-large-udp-response-00, it means "Use > Congestion Controlled Transport." > > I'd offer to move mine somewhere else, but it's been published as an RFC > already. > > /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 sip-bounces@ietf.org Mon Nov 06 18:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEHN-0004B0-5g; Mon, 06 Nov 2006 18:53:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEHL-00049K-Ks for sip@ietf.org; Mon, 06 Nov 2006 18:53:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEHK-0001Fe-A9 for sip@ietf.org; Mon, 06 Nov 2006 18:53:23 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 15:53:21 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="86390375:sNHT49162995" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6NrLsb018218; Mon, 6 Nov 2006 15:53:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6NrLAo014791; Mon, 6 Nov 2006 15:53:21 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 15:53:20 -0800 Received: from [10.21.81.168] ([10.21.81.168]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 15:53:20 -0800 Message-ID: <454FCAED.2070000@cisco.com> Date: Mon, 06 Nov 2006 18:53:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] Re: 489 status code References: <3B670951.93A4D00A@lmf.ericsson.se> <454E5CDA.6090207@nostrum.com> In-Reply-To: <454E5CDA.6090207@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 23:53:20.0700 (UTC) FILETIME=[BCF767C0:01C701FE] DKIM-Signature: a=rsa-sha1; q=dns; l=1208; t=1162857201; x=1163721201; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Re=3A=20489=20status=20code; X=v=3Dcisco.com=3B=20h=3Db8alGaibyFdgNLXeradZnqBCyVw=3D; b=UwevuhivJKYZR6PDoP3ngwa5h8fwYKXeVqh9tSrVh+OmcZ7rxOz+xU/ecCIkJhMdOMlg/Wpk MNc8NVpYTb2NckF00XUryrOTc0kFdobLPuidNwQ2gFdYYi1zygR60ydN; Authentication-Results: sj-dkim-3.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, Gonzalo Camarillo , adam.roach@ericsson.com, Jonathan Rosemberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I wonder if perhaps we need an shadow registry for SIP. It would hold new values that are being used in drafts until they become RFCs, after which they would go in the official IANA registry. (Would be better yet if IANA would do that for us, but that may be too much to expect.) Paul Adam Roach wrote: > On July 31, 2001, Gonzalo Camarillo wrote: >> A minor comment about 489 status code: In Adam's event draft it means >> "Bad Event", and in Jonathan's early media draft it means "Request >> Updated". Since both are just I-Ds this is not really an issue right >> now, but when they advance to RFCs we will have to resolve this >> conflict. > > ...and in draft-gurbani-sip-large-udp-response-00, it means "Use > Congestion Controlled Transport." > > I'd offer to move mine somewhere else, but it's been published as an RFC > already. > > /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 sip-bounces@ietf.org Mon Nov 06 19:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhER6-0003rJ-62; Mon, 06 Nov 2006 19:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhER5-0003rE-OA for sip@ietf.org; Mon, 06 Nov 2006 19:03:27 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEQY-0003Qv-4f for sip@ietf.org; Mon, 06 Nov 2006 19:03:27 -0500 Received: by nf-out-0910.google.com with SMTP id l23so2574317nfc for ; Mon, 06 Nov 2006 16:02:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TUY3GbhNvVIFiQ2qnpNcwmjqvQx3QnppwEhYJfFe+SEYEWkRjHlymiWQf/uZlGZXeejWWAnxPDLo+sqjOj8Zms/5lloKMd/88uVXXrKDDKAse7zn8O7nKC8D6yRx2SZMSJhhmaXmwiSlFm0CZBWwLfyvcrRKeBoK3yGzfwX66Sw= Received: by 10.78.26.9 with SMTP id 9mr4132389huz.1162857772210; Mon, 06 Nov 2006 16:02:52 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 6 Nov 2006 16:02:51 -0800 (PST) Message-ID: <953beacc0611061602r2303a9b4i9645327f9df22ce5@mail.gmail.com> Date: Mon, 6 Nov 2006 16:02:51 -0800 From: "Rohan Mahy" To: "Adam Roach" Subject: Re: [Sip] Outbound and SigComp In-Reply-To: <454E6189.1020002@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <454E6189.1020002@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 11/5/06, Adam Roach wrote: > Rohan: > > After reading through the new section in outbound relating to SigComp > (section 8.2), I have two small comments. > > The first is that STUN messages don't have any way to convey SigComp > compartment information. This is almost certainly okay, since the > document says to carry them using the "well known shim header," which > doesn't result in any attempt to create state. To avoid confusion, you > should add a paragraph to the end of the section reading something like: > > Because the bytecodes expressed in the well-known shim header do not > store any state, correlation of such SigComp requests to a > compartment is not necessary. To avoid ambiguity, we add the > following requirement: any SigComp state that may result from a > message that, once decompressed, turns out to be a STUN message, > MUST be discarded. While I really dislike being so pedantic, I added your proposed text. > Also, you cite the shim as coming from RFC 3320. In fact, it comes from > the implementors' guide, which in in WGLC: > draft-ietf-rohc-sigcomp-impl-guide-08.txt. actually we were both wrong. The well-known-shim is defined in: draft-ietf-rohc-sigcomp-sip-03.txt. I hope it is OK that this is an informative reference. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 19:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhF2j-0002tF-9T; Mon, 06 Nov 2006 19:42:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEgp-0002HX-Fv for sip@ietf.org; Mon, 06 Nov 2006 19:19:43 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEeN-0006bw-HO for sip@ietf.org; Mon, 06 Nov 2006 19:17:13 -0500 Received: from [130.129.68.74] (dhcp68-74.ietf67.org [130.129.68.74]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA6NKgEQ011739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Nov 2006 17:20:42 -0600 In-Reply-To: <002901c701ef$9f2a27a0$0601a8c0@BEMBUSTER> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com><45490C2C.3060606@cisco.com> <4549B645.50907@nokia.com><454BF20C.20608@cisco.com> <9CF79270-1876-4873-8C32-2ACB58982964@softarmor.com> <07de01c700fa$9448a000$0601a8c0@BEMBUSTER> <7A763EAD-0A39-4FE5-997F-BA3BC2D9C22B@softarmor.com> <002901c701ef$9f2a27a0$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EEB7565-0062-4015-85FC-4C6F4136ADD3@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning Date: Mon, 6 Nov 2006 18:16:57 -0600 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Joel M. Halpern" , 'IETF SIP List' , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 6, 2006, at 4:05 PM, Jeroen van Bemmel wrote: > Dean, > > I've just done some measurements. This is in no way representative > or statistically significant, but what I get on my PDA (Windows > Pocket PC 2003) on a commercial Dutch operator GPRS network (no > NAT) connecting to my home grown proxy at home (on ADSL and then > behind NAT): > > start-REGISTER-401-REGISTER-OK-end (starting with GPRS off, SIP UA > detects IP assignment and registers, times measured at UAC): > UDP : 2-3 seconds (T1=2 seconds, no retransmissions occur) > TCP: ~1 second connection setup, then 2-3 seconds > TLS: ~3 seconds handshake, then 2-3 seconds (without cert checking > etc) > > In all cases, a re-REGISTER sequence has similar timing. > > In other words: for my environment, once the connection is up, > round trip delay differences are indeed negligible > Cool. Thanks. That matches with my own informal observations. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 20:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNV-0002Ss-5b; Mon, 06 Nov 2006 20:03:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNU-0002RX-G8 for sip@ietf.org; Mon, 06 Nov 2006 20:03:48 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFNT-0006ql-5v for sip@ietf.org; Mon, 06 Nov 2006 20:03:48 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA713FB16086; Mon, 6 Nov 2006 20:03:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: TLS meaning Date: Mon, 6 Nov 2006 19:03:05 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F7DBCDB@zrc2hxm2.corp.nortel.com> In-Reply-To: <00b001c701f6$b315c740$0500a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: AccB1ZDIP6Dt6nIWTiuwYMl6kFTFxwAE4/2gAAKewHAABJ7zkA== From: "Samir Srivastava" To: "Hadriel Kaplan" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, In-line. Thx Samir >>=20 >> If M5 PUBLISH uses the SIPS URI, while in M1 WATCHER uses=20 >just the SIP=20 >> URI. Should we just leave the intermediary to distribute the=20 >presence=20 >> on the unsecure channel. IMHO, PUA should have the control for the=20 >> security where his presence info is going. Similar for REG-INFO. > >HK> If you want a UAC to control who gets to see its presence, that=20 >HK> should >be a package of/within presence, not a URI scheme or require=20 >of the subscribe or publish or whatever. The PUBLISH was=20 >addressed to the server, and it got there. If you use SIPS it=20 >will (hopefully) get there over TLS. > SS>> It's a question of feature. These cases are not considered earlier. Do we have in PIDF this support ? REGISTER just shows the IP Addresses etc. It doesn't have a body where you can embed this. > > >> Perfect. I too believe that we should not pose any limit on=20 >the secure=20 >> protocol to be used. I believe in separate header for describing the=20 >> complete secure protocol properties clearly, instead of=20 >embedding them=20 >> like SIPS means TLS over TCP in 3261. > >HK> I am in the exact opposite camp. I don't think an application=20 >HK> protocol >header should specify the transport type at all to be used for=20 >forward-routing by other nodes, let alone the intricate=20 >details of that transport. Do you expect to specify whether=20 >it can be UDP, TCP, or even the MTU as well? :) > >Encryption mechanisms in particular would be bad for this. =20 >There are so many optional/alternate components, that for a=20 >UAC to describe all the sets it will "allow" all proxies to=20 >use for transporting its message is just not practical. =20 >There's a reason negotiation mechanisms exist for encryption=20 >protocols, and even with them we have mismatches/failures. > >SIPS and SIP rely on trusting the proxies in the middle. If=20 >you don't trust them there's no point in adding more=20 >headers/checks when they can lie about any/all of them. If=20 >you DO trust them, then trust them to do the right thing. =20 >What they need from the UAC is to know whether the message is=20 >sensitive enough that it should not be forwarded if a secure=20 >next-hop path is not available.=20 > SS>> For Identity etc, people don't want to trust the intermediaries, But for the encryprion (where compromized hops reveal a lot) you want to trust them blindly. What you want to do where confidentiality is not permitted/provided due to whatever reasons ?=20 Imagine a UAS moves from the AES256 to NULL cipher region, shouldn't the UAC know about it ? Specially when it is IM with sensitive info in Payload without S/MIME.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 20:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG2i-0002At-Ku; Mon, 06 Nov 2006 20:46:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG2g-0001sp-Hz for sip@ietf.org; Mon, 06 Nov 2006 20:46:22 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhG2f-0003ei-9p for sip@ietf.org; Mon, 06 Nov 2006 20:46:22 -0500 Received: from [130.129.67.54] (dhcp67-54.ietf67.org [130.129.67.54]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kA71k6Js029143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 19:46:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <454FE545.4050107@nostrum.com> Date: Mon, 06 Nov 2006 17:45:41 -0800 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Outbound and SigComp References: <454E6189.1020002@nostrum.com> <953beacc0611061602r2303a9b4i9645327f9df22ce5@mail.gmail.com> In-Reply-To: <953beacc0611061602r2303a9b4i9645327f9df22ce5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.67.54 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP WG , Rohan Mahy , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > On 11/5/06, Adam Roach wrote: >> Also, you cite the shim as coming from RFC 3320. In fact, it comes from >> the implementors' guide, which in in WGLC: >> draft-ietf-rohc-sigcomp-impl-guide-08.txt. > > actually we were both wrong. The well-known-shim is defined in: > draft-ietf-rohc-sigcomp-sip-03.txt. Uh, no. I'm actually somewhat aware of the contents of the drafts I co-author. The shim is in draft-ietf-rohc-sigcomp-impl-guide-08.txt. Gonzalo copied it into draft-ietf-rohc-sigcomp-sip-03.txt due to some uncertainty on his part about the status of draft-ietf-rohc-sigcomp-impl-guide-08.txt. It will be removed in draft-ietf-rohc-sigcomp-sip-04.txt, never to reappear. You *REALLY* want to cite draft-ietf-rohc-sigcomp-impl-guide-08.txt I promise. /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 sip-bounces@ietf.org Mon Nov 06 21:00:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGEA-0000kj-NX; Mon, 06 Nov 2006 20:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGE8-0000kb-P9 for sip@ietf.org; Mon, 06 Nov 2006 20:58:12 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGE2-0004iX-51 for sip@ietf.org; Mon, 06 Nov 2006 20:58:12 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6F18B1287; Tue, 7 Nov 2006 02:58:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 02:58:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-05: Editorial comments Date: Tue, 7 Nov 2006 02:58:02 +0100 Message-ID: <7374777208BDC7449D5620EF942325672A1BC4@esealmw113.eemea.ericsson.se> In-Reply-To: <953beacc0611031516k5231eeccqc644c13e7b83cbcd@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-05: Editorial comments Thread-Index: Acb/niDzO8WK7Ba+TJqwMLkkN3LbKACZh0qw From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 07 Nov 2006 01:58:03.0610 (UTC) FILETIME=[2920DBA0:01C70210] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, Without commenting individual replies you gave, my main issue is that I want to be able to use STUN keep-alive without having to implement/use outbound, and I want that to be clear in the spec. So, if I only want to implement STUN keep-alive, and read chapter 8, I shouldn't have read or implement outbound, and I think that should be clearly indicated in the spec. Regards, Christer =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: 4. marraskuuta 2006 1:17 > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org; Rohan Mahy > Subject: Re: [Sip] Outbound-05: Editorial comments >=20 > Hi Christer, >=20 > Comments inline. >=20 > On 10/30/06, Christer Holmberg (JO/LMF)=20 > wrote: > > > > Hi, > > > > Some editorial comments on outbound-05: > > > > Abstract: > > --------- > > > > Instead of: > > > > "It also defines keep alive behaviors needed to keep NAT=20 > bindings open" > > > > ...I propose that we should say something like: > > > > "It also defines how SIP implements the STUN keepalive usage=20 > > [reference]" >=20 > I-D/RFC formatting guidelines prohibit references in the Abstract. >=20 > > Introduction: > > ------------- > > > > Instead of: > > > > "The key idea of this specification" > > > > ...I propose that we should say something like: > > > > "The key idea of the outbound mechanism defined in this=20 > specification" > > > > Because, the are two key ideas in the spec: the outbound=20 > mechanism and=20 > > the STUN keepalive for SIP. >=20 > No, the key idea in this specification is about=20 > oubound-initiated flows. STUN is a detail specified in a=20 > single chapter. >=20 > > Instead of: > > > > "This mechanism also uses a keep alive mechanism over each flow so=20 > > that the UA can detect when a flow has failed." > > > > ...I propose that we should say something like: > > > > "This specification also defines how SIP implements the=20 > STUN keepalive=20 > > usage. The keepalive mechanism is used by outbound to keep NAT=20 > > bindings, and to allow the UA to detect when a flow has failed. The=20 > > keepalive mechanism can also be used as a stand-alone function, or=20 > > together with other SIP extensions". >=20 > I am fine with your first two sentences. >=20 >=20 > > Chapter 3.5: > > ------------ > > > > Instead of: > > > > "This specification describes using STUN=20 > [I-D.ietf-behave-rfc3489bis]=20 > > over the same flow as the SIP traffic to perform the keepalive." > > > > ...I propose that we should say something like: > > > > "This specification describes the usage of the STUN keepalive usage=20 > > [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP=20 > traffic to=20 > > perform the keepalive. The SIP implementation of the STUN keepalive=20 > > usage is described in chapter 8 of this specification." >=20 > This change just seems to add extra bulk to the spec. I=20 > don't see how this makes anything clearer. >=20 > > Chapter 8: > > ---------- > > > > In generel I think this chapter is good, but I don't think=20 > we should=20 > > talk about "flows" here, becuase the chapter is not part of=20 > outbound=20 > > itself (I also still strongly think that we should define a=20 > flag which=20 > > can be inserted in Path/Service-Route, but that issue is=20 > discussed in=20 > > another thread). > > > > So, I think it would be enough to say something like: > > > > "The STUN messages can be used to verify that connectivity is still=20 > > available, and to provide periodic keepalives in order to keep NAT=20 > > bindings open. > > > > ...and: > > > > "A SIP node MUST NOT send STUN requests unless it has an explicit=20 > > indication that the target next hop SIP server claims to=20 > support STUN." >=20 > All the text in this section was put there to satisfy=20 > someone. We had consensus on the list to go forward with the=20 > proposal I described with respect to STUN. I believe this=20 > section accurately expresses that consensus and the email I=20 > sent out describing what I would do. >=20 > thanks, > -rohan >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 21:48:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxx-0002TN-7f; Mon, 06 Nov 2006 21:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxv-0002T6-7L for sip@ietf.org; Mon, 06 Nov 2006 21:45:31 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGxs-0003Ij-Ng for sip@ietf.org; Mon, 06 Nov 2006 21:45:31 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 18:45:28 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANaBT0WrR7MVh2dsb2JhbABEjAUBAQEIDio X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="448473995:sNHT47414792" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72jRJg023501 for ; Mon, 6 Nov 2006 18:45:27 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA72jRin011195 for ; Mon, 6 Nov 2006 18:45:27 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:27 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:27 -0800 Message-ID: <454FB793.7060107@cisco.com> Date: Mon, 06 Nov 2006 17:30:43 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:27.0614 (UTC) FILETIME=[C8496DE0:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=3924; t=1162867527; x=1163731527; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20draft-rosenberg-sip-outbound-discovery-mid-dialog=20-=20dhcp=20o veride=0A=20or=20not?; X=v=3Dcisco.com=3B=20h=3DWDzd8k3Xkppi69HPfbtj5CytjCM=3D; b=mqdqCcqLGYi9hEKSm61MBtmPQNylEVMyWI7Sji3OvnEi6oRz1NdxfZDPLfoTzwiv7Z8iaHwX OdRBanj8+Irg+M+vDnTzbUV6ELKkhmYBHxc+pMFyMoW5yLVG/byW3ixn; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: SIP Subject: [Sip] Re: draft-rosenberg-sip-outbound-discovery-mid-dialog - dhcp overide or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You raise an excellent point, Cullen. This is actually a pretty fundamental architectural issue that we need to discuss. Its much broader than the outbound discovery draft. The question is - if I'm "roaming" and my SIP UA finds itself in the domain of another IP access network provider (like a hotel), do I need to use its SIP services in order to communicate back to my home network? I think we've had this model for a long time that said you did, for things like firewall traversal and maybe even visited QoS authorization. The "hotel" proxy has been a staple of SIP thinking for a long time. However, there are several issues here: 1. first and foremost, I think the idea tha a visited *access* provider even needs to have application layer proxies (like a SIP proxy), is anathema to the entire IP model. The idea with IP is to separate access for applications. I should be able to get the SIP services from my SIP provider without the access network even knowing how to spell SIP. 2. With technologies like ICE, we have far better solutions for firewall traversal. The visited network (a hotel for example), could deploy a firewall, and black inbound packets unless a pinhole is opened from inside to out. The STUN checks would create such a pinhole, and it would not require any application layer intelligence in the firewall. 3. the issue Cullen has raised, whereby there is no trust with the visited network. Why would I include some unknown random proxy on my signaling path? They have no right to see my signaling, any more than they would have a right to view my web browsing. If folks agree to that, its not clear what to *do* about it. To some degree it implies we need to deprecate the entire usage of DHCP for discoverying proxy servers.... -Jonathan R. Cullen Jennings wrote: > > There is an issues about using outbound proxies discovered thought DHCP > where it is not clear to me what we want the solution to be. Once we > are clear on the desired behavior it is trivial to get the draft to > provide that. Let me try to describe the problem... > > If a phone has no configuration, no proxies, no aor etc and it gets > connected to the networks and finds out a proxy name via DHCP and uses > that to make outbound calls, I have no problem that is great. The > question is what happens with a phone that is configured, has a AOR, > credentials, etc. > > One view is that if DHCP returns a result, you use that as the > outbound. The argument will be made that this is the way you discover > the proxy in the hotel that lets you traverse the firewall. But > consider the security implications of this. It means that anyone that > spoof a DHCP response at a wireless hot spot can force you to connect > to them. Even if you are doing SIPS, you will pass all your signaling > through the attackers proxy and they will be able to see it all. > > Perhaps there is a part of this that I am missing but the more I think > about it, it does not seem like you want to actually use outbound > proxies that were discovered via DHCP. > > (Note this has nothing to do with a home proxy telling you to use a > proxy in a visited network - here someone you trust, the home proxy, > told you to trust the proxy in the visited network) > > > -------- > > One other trivial note - when talking about the names in the > certificates, I think the text needs to be updated a bit to cover > certificates that have more than one name in them > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 22:15:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHNr-0004ZF-Qc; Mon, 06 Nov 2006 22:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHNq-0004Z9-Kr for sip@ietf.org; Mon, 06 Nov 2006 22:12:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHNo-0007ZF-8e for sip@ietf.org; Mon, 06 Nov 2006 22:12:18 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 19:12:15 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="340159090:sNHT50561036" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73CFsT001782 for ; Mon, 6 Nov 2006 19:12:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA73CFbF004474 for ; Mon, 6 Nov 2006 19:12:15 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:12:15 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:12:15 -0800 Message-ID: <454FF98F.6010403@cisco.com> Date: Mon, 06 Nov 2006 22:12:15 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:12:15.0462 (UTC) FILETIME=[86A39060:01C7021A] DKIM-Signature: a=rsa-sha1; q=dns; l=1902; t=1162869135; x=1163733135; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=N8u6Dpr6QYSEHFPoJzskR22tZBA/PlD/XKylEbT6oxZWyMjYMXx8tvHRP7idk28zn8PeuQB1 iufV3eq4AFzPMBFiWI+ZPdygBSWIEYF5Omrt3K28ndiWxIT8m1hhnteK; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] ICE tutorial: Lunch logistics update [DO NOT REPLY] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 06 22:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHva-0005NC-CF; Mon, 06 Nov 2006 22:47:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHvY-0005Me-Mi for sip@ietf.org; Mon, 06 Nov 2006 22:47:08 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHvW-0002T3-4J for sip@ietf.org; Mon, 06 Nov 2006 22:47:08 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id D9AF62062E for ; Tue, 7 Nov 2006 09:11:32 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id BF48E205DA for ; Tue, 7 Nov 2006 09:11:32 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 09:17:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Date: Tue, 7 Nov 2006 09:17:01 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD4AB01A9@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Thread-Index: Acb735DO2hLdDQoLSyisDLk4w7jBbgABPjwwAC9h5DABEXRlMABNzAuw From: To: , X-OriginalArrivalTime: 07 Nov 2006 03:47:02.0571 (UTC) FILETIME=[62A71FB0:01C7021F] X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thank you very much for the comments. We will be working on Draft to make it clearer with the comments=20 Incorporated. We will also address the Draft for comments in the SIPPING. Regards, Sreeram. -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Monday, November 06, 2006 2:10 AM To: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks); sip@ietf.org Subject: RE: [Sip] Draft for review:draft-sreeram-specify-method-00.txt (As individual) I had a brief look at this draft. It would seem to me that proxies could be considered in networks as two forms: - As edge proxies, where we have the only mechanism of routeing to or from the user. - As "routeing" proxies, where the aim is to provide connectivity from one SIP proxy to another. For the first set, I think you need to provide some discussion in your draft of why outbound does not support your needs, i.e. what capabilities you do not get from outbound but which you do get from your proposals. For the second set, we would seem to be straying into the overall area that touches congestion control (where out of service is an extreme form of congestion). I would like to see some discussion of how this does not or does relate to the mechanisms being discussed in SIPPING to support congestion control. Finally you have plumped straight away for a new method and header in SIP. Why is it appropriate to use SIP to do this rather than some other protocol running between the two entities? I think you should also consider addressing this document to SIPPING, and concentrating foremost on the requirements you need to fulfil rather than the protocol solution. Regards Keith > -----Original Message----- > From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com]=20 > Sent: 31 October 2006 04:15 > To: sip@ietf.org > Subject: FW: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > Fwding the mail to the list. > I did a reply , should have done reply all. >=20 > Thanks Dale for pointing this. >=20 > -Sreeram. >=20 > -----Original Message----- > From: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks) > Sent: Monday, October 30, 2006 11:21 AM > To: 'Dale.Worley@comcast.net' > Subject: RE: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > Hi Dale, >=20 > There are 2 Cases > Proxy with backup: Means there is inactive unit. Which will=20 > take over when the active proxy is taken out (Duplex) >=20 > Proxy without backup: These are proxies which work as stand-alone. > Proxies to be stand alone are generally very rare in field=20 > but can be possible. >=20 > When we say a Proxy with out backup giving the alternative ip=20 > address is the case when standalone proxy (P1) is giving the=20 > details of proxy P2 . >=20 > The use cases have shown some of these cases. >=20 > We will take care that the sentence is reformatted in the=20 > next release to make it clear. >=20 > Regards, > Sreeram >=20 >=20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Monday, October 30, 2006 10:19 AM > To: sip@ietf.org > Subject: Re: [Sip] Draft for=20 > review:draft-sreeram-specify-method-00.txt >=20 > You write: >=20 > Similarly, on restart/disconnect of a SIP entity without=20 > backup, the > same problem exists and there is no way by which SIP entity that is > restarting/disconnecting can inform about the alternative=20 > IP address > (if available) to other SIP entities to which it can communicate so > that graceful handling of existing sessions (or calls) or future > sessions can be performed using alternate IP address. >=20 > I don't understand what the "alternate IP address" can be --=20 > you've already said the SIP entity does not have a backup, so=20 > there can be no alternate IP address at which to contact the backup. >=20 > Dale >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 00:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhJ4p-00086N-S0; Tue, 07 Nov 2006 00:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhJ4o-00085x-4z; Tue, 07 Nov 2006 00:00:46 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhJ4j-0008OI-Nj; Tue, 07 Nov 2006 00:00:46 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id kA750OBU013222; Mon, 6 Nov 2006 21:00:24 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id kA750I4J013221; Mon, 6 Nov 2006 21:00:24 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Mon, 06 Nov 2006 21:00:17 -0800 (PST) Date: Mon, 6 Nov 2006 21:00:14 -0800 From: Marc Petit-Huguenin To: "Drage, Keith \(Keith\)" Message-ID: <455012DE.2030604@acm.org> In-Reply-To: <5D1A7985295922448D5550C94DE2918072B807@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE2918072B807@DEEXC1U01.de.lucent.com> Subject: Re: [Sip] Re: 489 status code x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.7 (X11/20061013) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, sipping@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) wrote: > (As SIP WG chair) > > See http://www.iana.org/assignments/sip-parameters for a list of > currently assigned response codes (with 489 allocated already as Adam > indicates). > > As definition of a new response code requires a SIP WG document, can I > suggest that only such documents make any attempt to assign a response > code value - I know this can be useful because the examples have to show > it. If your document is not one of these, use 4xx or something else that > can be replaced later. Using 4xx can be confusing as there will be no way to know if it is an yet unassigned specific response code in the 4xx class or the whole 4xx class. May I suggest 4?? instead? > > I notice also drafts in SIPPING group attempting to assign response > codes. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 01:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKkP-0006GI-Ni; Tue, 07 Nov 2006 01:47:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKkN-0006GD-V7 for sip@ietf.org; Tue, 07 Nov 2006 01:47:47 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhKkM-0003qd-Kc for sip@ietf.org; Tue, 07 Nov 2006 01:47:47 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id A8809AC283; Tue, 7 Nov 2006 08:47:44 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17744.11280.635600.921584@harjus.tutpro.com> Date: Tue, 7 Nov 2006 08:47:44 +0200 To: Jonathan Rosenberg Subject: [Sip] Re: draft-rosenberg-sip-outbound-discovery-mid-dialog - dhcp overide or not? In-Reply-To: <454FB793.7060107@cisco.com> References: <454FB793.7060107@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > If folks agree to that, its not clear what to *do* about it. To some > degree it implies we need to deprecate the entire usage of DHCP for > discoverying proxy servers.... the idea of using visiting network's sip resources is completely bogus and so is dhcp configuration of sip ua. the idea of using visited network's sip resources is yet another bad idea that 3gpp has adopted for the sole reason of being able to milk the cow as many times as possible. in order to support dhcp free configuration of sip ua, we should have included jonathan's outbound autodiscovery mechanism in outbound, but for some reason, some people didn't agree to it. -- juah _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 02:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKxa-00089Q-FQ; Tue, 07 Nov 2006 02:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKxY-00089D-Is for sip@ietf.org; Tue, 07 Nov 2006 02:01:24 -0500 Received: from bayc1-pasmtp02.bayc1.hotmail.com ([65.54.191.162] helo=BAYC1-PASMTP02.CEZ.ICE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhKxS-0005N0-4C for sip@ietf.org; Tue, 07 Nov 2006 02:01:24 -0500 Message-ID: X-Originating-IP: [130.129.65.197] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([130.129.65.197]) by BAYC1-PASMTP02.CEZ.ICE over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 23:01:16 -0800 Message-ID: <009d01c7023a$81b85b10$c5418182@ronin> From: "Eric Cooper" To: "Christer Holmberg \(JO/LMF\)" , "Rohan Mahy" References: <7374777208BDC7449D5620EF942325672A1BC4@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Outbound-05: Editorial comments Date: Mon, 6 Nov 2006 23:00:47 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 07 Nov 2006 07:01:17.0071 (UTC) FILETIME=[8546B1F0:01C7023A] X-Spam-Score: 2.3 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736098822==" Errors-To: sip-bounces@ietf.org --===============0736098822== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0ZXIsDQoNCklmIHlvdSdyZSBvbmx5IGludGVyZXN0ZWQgaW4gY2hhcHRlciA4IChh bmQgeW91J3JlIHByb2JhYmx5IG5vdCBhbG9uZSksIHdvdWxkbid0IGl0IG1ha2UgbW9yZSBzZW5z ZSBpZiB0aGUgU1RVTiwga2VlcC1hbGl2ZSB1c2FnZSB3ZXJlIGRlc2NyaWJlZCBpbiBhIHNlcGFy YXRlIGRyYWZ0Pw0KDQpCZXN0IFJlZ2FyZHMsDQoNCkVyaWMgQ29vcGVyLg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzdGVyIEhvbG1iZXJnIChKTy9MTUYpIiA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KVG86ICJSb2hhbiBNYWh5IiA8cm9oYW4u bWFoeUBnbWFpbC5jb20+DQpDYzogPHNpcEBpZXRmLm9yZz47ICJSb2hhbiBNYWh5IiA8cm9oYW5A ZWthYmFsLmNvbT4NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDYsIDIwMDYgNTo1OCBQTQ0KU3Vi amVjdDogUkU6IFtTaXBdIE91dGJvdW5kLTA1OiBFZGl0b3JpYWwgY29tbWVudHMNCg0KDQoNCkhp IFJvaGFuLA0KDQpXaXRob3V0IGNvbW1lbnRpbmcgaW5kaXZpZHVhbCByZXBsaWVzIHlvdSBnYXZl LCBteSBtYWluIGlzc3VlIGlzIHRoYXQgSQ0Kd2FudCB0byBiZSBhYmxlIHRvIHVzZSBTVFVOIGtl ZXAtYWxpdmUgd2l0aG91dCBoYXZpbmcgdG8gaW1wbGVtZW50L3VzZQ0Kb3V0Ym91bmQsIGFuZCBJ IHdhbnQgdGhhdCB0byBiZSBjbGVhciBpbiB0aGUgc3BlYy4NCg0KU28sIGlmIEkgb25seSB3YW50 IHRvIGltcGxlbWVudCBTVFVOIGtlZXAtYWxpdmUsIGFuZCByZWFkIGNoYXB0ZXIgOCwgSQ0Kc2hv dWxkbid0IGhhdmUgcmVhZCBvciBpbXBsZW1lbnQgb3V0Ym91bmQsIGFuZCBJIHRoaW5rIHRoYXQg c2hvdWxkIGJlDQpjbGVhcmx5IGluZGljYXRlZCBpbiB0aGUgc3BlYy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBSb2hhbiBNYWh5IFttYWlsdG86cm9oYW4ubWFoeUBnbWFpbC5jb21dIA0KPiBTZW50OiA0LiBt YXJyYXNrdXV0YSAyMDA2IDE6MTcNCj4gVG86IENocmlzdGVyIEhvbG1iZXJnIChKTy9MTUYpDQo+ IENjOiBzaXBAaWV0Zi5vcmc7IFJvaGFuIE1haHkNCj4gU3ViamVjdDogUmU6IFtTaXBdIE91dGJv dW5kLTA1OiBFZGl0b3JpYWwgY29tbWVudHMNCj4gDQo+IEhpIENocmlzdGVyLA0KPiANCj4gQ29t bWVudHMgaW5saW5lLg0KPiANCj4gT24gMTAvMzAvMDYsIENocmlzdGVyIEhvbG1iZXJnIChKTy9M TUYpIA0KPiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gPg0KPiA+ IEhpLA0KPiA+DQo+ID4gU29tZSBlZGl0b3JpYWwgY29tbWVudHMgb24gb3V0Ym91bmQtMDU6DQo+ ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAtLS0tLS0tLS0NCj4gPg0KPiA+IEluc3RlYWQgb2Y6DQo+ ID4NCj4gPiAiSXQgYWxzbyBkZWZpbmVzIGtlZXAgYWxpdmUgYmVoYXZpb3JzIG5lZWRlZCB0byBr ZWVwIE5BVCANCj4gYmluZGluZ3Mgb3BlbiINCj4gPg0KPiA+IC4uLkkgcHJvcG9zZSB0aGF0IHdl IHNob3VsZCBzYXkgc29tZXRoaW5nIGxpa2U6DQo+ID4NCj4gPiAiSXQgYWxzbyBkZWZpbmVzIGhv dyBTSVAgaW1wbGVtZW50cyB0aGUgU1RVTiBrZWVwYWxpdmUgdXNhZ2UgDQo+ID4gW3JlZmVyZW5j ZV0iDQo+IA0KPiBJLUQvUkZDIGZvcm1hdHRpbmcgZ3VpZGVsaW5lcyBwcm9oaWJpdCByZWZlcmVu Y2VzIGluIHRoZSBBYnN0cmFjdC4NCj4gDQo+ID4gSW50cm9kdWN0aW9uOg0KPiA+IC0tLS0tLS0t LS0tLS0NCj4gPg0KPiA+IEluc3RlYWQgb2Y6DQo+ID4NCj4gPiAiVGhlIGtleSBpZGVhIG9mIHRo aXMgc3BlY2lmaWNhdGlvbiINCj4gPg0KPiA+IC4uLkkgcHJvcG9zZSB0aGF0IHdlIHNob3VsZCBz YXkgc29tZXRoaW5nIGxpa2U6DQo+ID4NCj4gPiAiVGhlIGtleSBpZGVhIG9mIHRoZSBvdXRib3Vu ZCBtZWNoYW5pc20gZGVmaW5lZCBpbiB0aGlzIA0KPiBzcGVjaWZpY2F0aW9uIg0KPiA+DQo+ID4g QmVjYXVzZSwgdGhlIGFyZSB0d28ga2V5IGlkZWFzIGluIHRoZSBzcGVjOiB0aGUgb3V0Ym91bmQg DQo+IG1lY2hhbmlzbSBhbmQgDQo+ID4gdGhlIFNUVU4ga2VlcGFsaXZlIGZvciBTSVAuDQo+IA0K PiBObywgdGhlIGtleSBpZGVhIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhYm91dCANCj4gb3Vi b3VuZC1pbml0aWF0ZWQgZmxvd3MuICBTVFVOIGlzIGEgZGV0YWlsIHNwZWNpZmllZCBpbiBhIA0K PiBzaW5nbGUgY2hhcHRlci4NCj4gDQo+ID4gSW5zdGVhZCBvZjoNCj4gPg0KPiA+ICJUaGlzIG1l Y2hhbmlzbSBhbHNvIHVzZXMgYSBrZWVwIGFsaXZlIG1lY2hhbmlzbSBvdmVyIGVhY2ggZmxvdyBz byANCj4gPiB0aGF0IHRoZSBVQSBjYW4gZGV0ZWN0IHdoZW4gYSBmbG93IGhhcyBmYWlsZWQuIg0K PiA+DQo+ID4gLi4uSSBwcm9wb3NlIHRoYXQgd2Ugc2hvdWxkIHNheSBzb21ldGhpbmcgbGlrZToN Cj4gPg0KPiA+ICJUaGlzIHNwZWNpZmljYXRpb24gYWxzbyBkZWZpbmVzIGhvdyBTSVAgaW1wbGVt ZW50cyB0aGUgDQo+IFNUVU4ga2VlcGFsaXZlIA0KPiA+IHVzYWdlLiBUaGUga2VlcGFsaXZlIG1l Y2hhbmlzbSBpcyB1c2VkIGJ5IG91dGJvdW5kIHRvIGtlZXAgTkFUIA0KPiA+IGJpbmRpbmdzLCBh bmQgdG8gYWxsb3cgdGhlIFVBIHRvIGRldGVjdCB3aGVuIGEgZmxvdyBoYXMgZmFpbGVkLiBUaGUg DQo+ID4ga2VlcGFsaXZlIG1lY2hhbmlzbSBjYW4gYWxzbyBiZSB1c2VkIGFzIGEgc3RhbmQtYWxv bmUgZnVuY3Rpb24sIG9yIA0KPiA+IHRvZ2V0aGVyIHdpdGggb3RoZXIgU0lQIGV4dGVuc2lvbnMi Lg0KPiANCj4gSSBhbSBmaW5lIHdpdGggeW91ciBmaXJzdCB0d28gc2VudGVuY2VzLg0KPiANCj4g DQo+ID4gQ2hhcHRlciAzLjU6DQo+ID4gLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBJbnN0ZWFkIG9m Og0KPiA+DQo+ID4gIlRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgdXNpbmcgU1RVTiANCj4g W0ktRC5pZXRmLWJlaGF2ZS1yZmMzNDg5YmlzXSANCj4gPiBvdmVyIHRoZSBzYW1lIGZsb3cgYXMg dGhlIFNJUCB0cmFmZmljIHRvIHBlcmZvcm0gdGhlIGtlZXBhbGl2ZS4iDQo+ID4NCj4gPiAuLi5J IHByb3Bvc2UgdGhhdCB3ZSBzaG91bGQgc2F5IHNvbWV0aGluZyBsaWtlOg0KPiA+DQo+ID4gIlRo aXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgdGhlIHVzYWdlIG9mIHRoZSBTVFVOIGtlZXBhbGl2 ZSB1c2FnZSANCj4gPiBbSS1ELmlldGYtYmVoYXZlLXJmYzM0ODliaXNdIG92ZXIgdGhlIHNhbWUg ZmxvdyBhcyB0aGUgU0lQIA0KPiB0cmFmZmljIHRvIA0KPiA+IHBlcmZvcm0gdGhlIGtlZXBhbGl2 ZS4gVGhlIFNJUCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgU1RVTiBrZWVwYWxpdmUgDQo+ID4gdXNh Z2UgaXMgZGVzY3JpYmVkIGluIGNoYXB0ZXIgOCBvZiB0aGlzIHNwZWNpZmljYXRpb24uIg0KPiAN Cj4gVGhpcyBjaGFuZ2UganVzdCBzZWVtcyB0byBhZGQgZXh0cmEgYnVsayB0byB0aGUgc3BlYy4g IEkgDQo+IGRvbid0IHNlZSBob3cgdGhpcyBtYWtlcyBhbnl0aGluZyBjbGVhcmVyLg0KPiANCj4g PiBDaGFwdGVyIDg6DQo+ID4gLS0tLS0tLS0tLQ0KPiA+DQo+ID4gSW4gZ2VuZXJlbCBJIHRoaW5r IHRoaXMgY2hhcHRlciBpcyBnb29kLCBidXQgSSBkb24ndCB0aGluayANCj4gd2Ugc2hvdWxkIA0K PiA+IHRhbGsgYWJvdXQgImZsb3dzIiBoZXJlLCBiZWN1YXNlIHRoZSBjaGFwdGVyIGlzIG5vdCBw YXJ0IG9mIA0KPiBvdXRib3VuZCANCj4gPiBpdHNlbGYgKEkgYWxzbyBzdGlsbCBzdHJvbmdseSB0 aGluayB0aGF0IHdlIHNob3VsZCBkZWZpbmUgYSANCj4gZmxhZyB3aGljaCANCj4gPiBjYW4gYmUg aW5zZXJ0ZWQgaW4gUGF0aC9TZXJ2aWNlLVJvdXRlLCBidXQgdGhhdCBpc3N1ZSBpcyANCj4gZGlz Y3Vzc2VkIGluIA0KPiA+IGFub3RoZXIgdGhyZWFkKS4NCj4gPg0KPiA+IFNvLCBJIHRoaW5rIGl0 IHdvdWxkIGJlIGVub3VnaCB0byBzYXkgc29tZXRoaW5nIGxpa2U6DQo+ID4NCj4gPiAiVGhlIFNU VU4gbWVzc2FnZXMgY2FuIGJlIHVzZWQgdG8gdmVyaWZ5IHRoYXQgY29ubmVjdGl2aXR5IGlzIHN0 aWxsIA0KPiA+IGF2YWlsYWJsZSwgYW5kIHRvIHByb3ZpZGUgcGVyaW9kaWMga2VlcGFsaXZlcyBp biBvcmRlciB0byBrZWVwIE5BVCANCj4gPiBiaW5kaW5ncyBvcGVuLg0KPiA+DQo+ID4gLi4uYW5k Og0KPiA+DQo+ID4gIkEgU0lQIG5vZGUgTVVTVCBOT1Qgc2VuZCBTVFVOIHJlcXVlc3RzIHVubGVz cyBpdCBoYXMgYW4gZXhwbGljaXQgDQo+ID4gaW5kaWNhdGlvbiB0aGF0IHRoZSB0YXJnZXQgbmV4 dCBob3AgU0lQIHNlcnZlciBjbGFpbXMgdG8gDQo+IHN1cHBvcnQgU1RVTi4iDQo+IA0KPiBBbGwg dGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uIHdhcyBwdXQgdGhlcmUgdG8gc2F0aXNmeSANCj4gc29t ZW9uZS4gIFdlIGhhZCBjb25zZW5zdXMgb24gdGhlIGxpc3QgdG8gZ28gZm9yd2FyZCB3aXRoIHRo ZSANCj4gcHJvcG9zYWwgSSBkZXNjcmliZWQgd2l0aCByZXNwZWN0IHRvIFNUVU4uICBJIGJlbGll dmUgdGhpcyANCj4gc2VjdGlvbiBhY2N1cmF0ZWx5IGV4cHJlc3NlcyB0aGF0IGNvbnNlbnN1cyBh bmQgdGhlIGVtYWlsIEkgDQo+IHNlbnQgb3V0IGRlc2NyaWJpbmcgd2hhdCBJIHdvdWxkIGRvLg0K PiANCj4gdGhhbmtzLA0KPiAtcm9oYW4NCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3Bt ZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29s dW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANClVzZSBzaXBwaW5nQGlldGYu b3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXA= --===============0736098822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0736098822==-- From sip-bounces@ietf.org Tue Nov 07 02:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLhv-00033W-Tz; Tue, 07 Nov 2006 02:49:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLht-00033E-Rg for sip@ietf.org; Tue, 07 Nov 2006 02:49:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhLhn-0002lk-5o for sip@ietf.org; Tue, 07 Nov 2006 02:49:17 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 15DB2697; Tue, 7 Nov 2006 08:48:54 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 08:48:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-05: Editorial comments Date: Tue, 7 Nov 2006 08:48:48 +0100 Message-ID: <7374777208BDC7449D5620EF942325672A1FFE@esealmw113.eemea.ericsson.se> In-Reply-To: <009d01c7023a$81b85b10$c5418182@ronin> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-05: Editorial comments Thread-Index: AccCOodESNZXxAl4QTGatWI/3vtKmgABhPyg From: "Christer Holmberg \(JO/LMF\)" To: "Eric Cooper" , "Rohan Mahy" X-OriginalArrivalTime: 07 Nov 2006 07:48:54.0123 (UTC) FILETIME=[2C363BB0:01C70241] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >If you're only interested in chapter 8 (and you're probably=20 >not alone), wouldn't it make more sense if the STUN,=20 >keep-alive usage were described in a separate draft? Well, that is what I proposed before, when commenting outbound-04.=20 But, the decission that seems to have been made at some meeting was to keep it in the outbound draft. And I can live with that, as long as it is clearly separated from the outbound mechanism, which I don't think it is - eventhough the addition of chapter 8 IS a good improvement from outbound-04. Regards, Christer > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Rohan Mahy" > Cc: ; "Rohan Mahy" > Sent: Monday, November 06, 2006 5:58 PM > Subject: RE: [Sip] Outbound-05: Editorial comments >=20 >=20 >=20 > Hi Rohan, >=20 > Without commenting individual replies you gave, my main issue=20 > is that I > want to be able to use STUN keep-alive without having to implement/use > outbound, and I want that to be clear in the spec. >=20 > So, if I only want to implement STUN keep-alive, and read chapter 8, I > shouldn't have read or implement outbound, and I think that should be > clearly indicated in the spec. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > > Sent: 4. marraskuuta 2006 1:17 > > To: Christer Holmberg (JO/LMF) > > Cc: sip@ietf.org; Rohan Mahy > > Subject: Re: [Sip] Outbound-05: Editorial comments > >=20 > > Hi Christer, > >=20 > > Comments inline. > >=20 > > On 10/30/06, Christer Holmberg (JO/LMF)=20 > > wrote: > > > > > > Hi, > > > > > > Some editorial comments on outbound-05: > > > > > > Abstract: > > > --------- > > > > > > Instead of: > > > > > > "It also defines keep alive behaviors needed to keep NAT=20 > > bindings open" > > > > > > ...I propose that we should say something like: > > > > > > "It also defines how SIP implements the STUN keepalive usage=20 > > > [reference]" > >=20 > > I-D/RFC formatting guidelines prohibit references in the Abstract. > >=20 > > > Introduction: > > > ------------- > > > > > > Instead of: > > > > > > "The key idea of this specification" > > > > > > ...I propose that we should say something like: > > > > > > "The key idea of the outbound mechanism defined in this=20 > > specification" > > > > > > Because, the are two key ideas in the spec: the outbound=20 > > mechanism and=20 > > > the STUN keepalive for SIP. > >=20 > > No, the key idea in this specification is about=20 > > oubound-initiated flows. STUN is a detail specified in a=20 > > single chapter. > >=20 > > > Instead of: > > > > > > "This mechanism also uses a keep alive mechanism over=20 > each flow so=20 > > > that the UA can detect when a flow has failed." > > > > > > ...I propose that we should say something like: > > > > > > "This specification also defines how SIP implements the=20 > > STUN keepalive=20 > > > usage. The keepalive mechanism is used by outbound to keep NAT=20 > > > bindings, and to allow the UA to detect when a flow has=20 > failed. The=20 > > > keepalive mechanism can also be used as a stand-alone=20 > function, or=20 > > > together with other SIP extensions". > >=20 > > I am fine with your first two sentences. > >=20 > >=20 > > > Chapter 3.5: > > > ------------ > > > > > > Instead of: > > > > > > "This specification describes using STUN=20 > > [I-D.ietf-behave-rfc3489bis]=20 > > > over the same flow as the SIP traffic to perform the keepalive." > > > > > > ...I propose that we should say something like: > > > > > > "This specification describes the usage of the STUN=20 > keepalive usage=20 > > > [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP=20 > > traffic to=20 > > > perform the keepalive. The SIP implementation of the STUN=20 > keepalive=20 > > > usage is described in chapter 8 of this specification." > >=20 > > This change just seems to add extra bulk to the spec. I=20 > > don't see how this makes anything clearer. > >=20 > > > Chapter 8: > > > ---------- > > > > > > In generel I think this chapter is good, but I don't think=20 > > we should=20 > > > talk about "flows" here, becuase the chapter is not part of=20 > > outbound=20 > > > itself (I also still strongly think that we should define a=20 > > flag which=20 > > > can be inserted in Path/Service-Route, but that issue is=20 > > discussed in=20 > > > another thread). > > > > > > So, I think it would be enough to say something like: > > > > > > "The STUN messages can be used to verify that=20 > connectivity is still=20 > > > available, and to provide periodic keepalives in order to=20 > keep NAT=20 > > > bindings open. > > > > > > ...and: > > > > > > "A SIP node MUST NOT send STUN requests unless it has an explicit=20 > > > indication that the target next hop SIP server claims to=20 > > support STUN." > >=20 > > All the text in this section was put there to satisfy=20 > > someone. We had consensus on the list to go forward with the=20 > > proposal I described with respect to STUN. I believe this=20 > > section accurately expresses that consensus and the email I=20 > > sent out describing what I would do. > >=20 > > thanks, > > -rohan > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 03:15:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhM4p-0000Qv-Sf; Tue, 07 Nov 2006 03:12:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhM4o-0000Ql-5Z; Tue, 07 Nov 2006 03:12:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhM4m-0005xQ-Ne; Tue, 07 Nov 2006 03:12:58 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2006 00:12:56 -0800 X-IronPort-AV: i="4.09,394,1157353200"; d="scan'208"; a="86524540:sNHT43308801" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA78CuXW027228; Tue, 7 Nov 2006 00:12:56 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA78CuAo003276; Tue, 7 Nov 2006 00:12:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 00:12:55 -0800 Received: from [130.129.71.49] ([10.21.80.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 00:12:55 -0800 Message-ID: <45504007.7010301@cisco.com> Date: Tue, 07 Nov 2006 03:12:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List , IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 08:12:55.0612 (UTC) FILETIME=[8767FFC0:01C70244] DKIM-Signature: a=rsa-sha1; q=dns; l=435; t=1162887176; x=1163751176; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=20slides=20for=20tomorrow; X=v=3Dcisco.com=3B=20h=3D5VVvK83NIHToiZMLcIb/SaJwnHE=3D; b=WQDpWkoTmVJEoR28O2CjztC3bWaKE17jjGLh/F+uPtOWAKmwkcFH5O5YnPFJW+0F8XQPvVcY X0OLhcy2R7QOT8pzJAJkOUBN8j9En3sMaDw4IsQ9Zhe+HPbyyAhpCvh+; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Sip] ICE tutorial slides for tomorrow X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Tutorial slides can be found here: http://www.jdrosen.net/papers/ice-ietf-tutorial.pdf Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From akstcbapolymnsdgs@bapoly.com Tue Nov 07 05:56:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhOd1-0004LB-HQ for sip-archive@lists.ietf.org; Tue, 07 Nov 2006 05:56:27 -0500 Received: from [222.185.114.83] (helo=fornax.avernus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhOcw-0000Kf-K8 for sip-archive@lists.ietf.org; Tue, 07 Nov 2006 05:56:25 -0500 Received: from 216.82.249.3 (HELO cluster2.us.messagelabs.com) by lists.ietf.org with esmtp (XKSR1OL920 69G4) id NMBVSZ-G2ROQP-60 for sip-archive@lists.ietf.org; Tue, 7 Dec 2006 10:49:25 -0480 Date: Tue, 7 Dec 2006 10:49:25 -0480 From: "Emmanuel Gray" X-Mailer: The Bat! (v2.11) Business X-Priority: 3 (Normal) Message-ID: <245338584.25129290077840@thebat.net> To: sip-archive@lists.ietf.org Subject: Feel strong MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 4.1 (++++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c RREF Pricte Settles And On The Rise! Time To Get In Is Now! Red Reef Labs For New Manufacturing anwd Distribution Contract In=20= China! Compavny red Reef Laboratozries Inc. Symbol: RREF Price: $0.352 Volume Expectations: Huge RREF has been climbing up and down the pricie ladder due to so many=20= changes in the marekt and this companyies dynamic directions and news relesaes. The pricfe has settled and Volubme is rising as investoxrs are jumping=20= in before the climb. Just look at some of the releases over the last 4 weeks. This one will climb hard. They have news cominpg out end of week and it is expected to push this up 300%. READ up on the news. LOOK at the amazing potential and. GET into RREF Tuesday, Mornirng! before the climb continues. I hope it was a helper. I'll email you later this week. Emmanuel Gray. at length every idea seemed to fail him; and, after standing a few=20= moments without saying a elizabeth, on her side, had much to do. she wanted to ascertain the=20= feelings of each of her "you mistake me, my dear. i have a high respect for your nerves. they=20= are my old friends. i have as to your other objection, i am afraid it will hardly hold good. lydia=20= has no brothers to step forward; due." a way off. must it be so?" =D7not turned out well. at such a distance as that , you know, things=20= are strangely darcy was here when you sent for us; was it so?" before me. these causes must be stated, though briefly. the situation of=20= your mother's family, though amiable feeling; that had his actions been what mr. wickham represented=20= them, so gross a violation of demean myself with grateful respect towards her ladyship, and be ever=20= ready to perform those rites and and gratitude by scotch and irish airs, at the request of her younger=20= sisters, who, with some of the away ran the girls, too eager to get in to have time for speech. they=20= ran through the vestibule bore it; but jane was very composedly talking to bingley. she looked at=20= his two sisters, and saw them could hardly keep her seat. it drew from her, however, the exertion of=20= speaking, which nothing else collins, to be sure, was neither sensible nor agreeable; his society was=20= irksome, and his attachment to From sip-bounces@ietf.org Tue Nov 07 08:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhR6r-0002lb-Un; Tue, 07 Nov 2006 08:35:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhR6q-0002jC-DT for sip@ietf.org; Tue, 07 Nov 2006 08:35:24 -0500 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhR6p-00054o-0B for sip@ietf.org; Tue, 07 Nov 2006 08:35:24 -0500 Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id A5FAA8734C for ; Tue, 7 Nov 2006 13:35:11 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Nov 2006 13:35:11 -0000 Message-ID: <00D42150952F70458C66072322F7FE250B0BEF@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3261 Ambiguous SIP URI table in 19.1.1 thread-index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZg== From: "Matthew Gardiner" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0717544765==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0717544765== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70271.8C5AEF67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70271.8C5AEF67 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am attempting to tighten up our SIP stack's behaviour regarding which = URI parameters/fields to display/hide in header fields. This quest led = me to a table known as "Table 1" in section 19.1.1(?) of RFC 3261. This = table seems to present whether or not fields such as port and transport = are optional or mandatory in headers, such as the "Contact" header. My = understanding of this table leads me to believe that the only mandatory = field for all header categories is the host address - that's why an 'm' = character only appears in the "host" row. So, apparently, all of the other fields are either optional or not = allowed. Surely this constraint only applies when those fields have a = their default value? What happens if a field assumes a non-default = value, surely then the presentation of this value becomes mandatory in = some header field somewhere? Could someone clarify how, if at all, this table is to be interpreted = regarding non-default values for URI parameters/fields? thanks Matt =20 ------_=_NextPart_001_01C70271.8C5AEF67 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 3261 Ambiguous SIP URI table in 19.1.1

Hi,

I am attempting to tighten up our SIP = stack's behaviour regarding which URI parameters/fields to display/hide = in header fields. This quest led me to a table known as "Table = 1" in section 19.1.1(?) of RFC 3261. This table seems to present = whether or not fields such as port and transport are optional or = mandatory in headers, such as the "Contact" header. My = understanding of this table leads me to believe that the only mandatory = field for all header categories is the host address - that's why an 'm' = character only appears in the "host" row.

So, apparently, all of the other fields = are either optional or not allowed. Surely this constraint only applies = when those fields have a their default value? What happens if a field = assumes a non-default value, surely then the presentation of this value = becomes mandatory in some header field somewhere?

Could someone clarify how, if at all, = this table is to be interpreted regarding non-default values for URI = parameters/fields?

thanks
Matt  

------_=_NextPart_001_01C70271.8C5AEF67-- --===============0717544765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0717544765==-- From sip-bounces@ietf.org Tue Nov 07 11:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTQ2-0000n5-1l; Tue, 07 Nov 2006 11:03:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTPy-0000lQ-QZ; Tue, 07 Nov 2006 11:03:18 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTPw-00022d-Db; Tue, 07 Nov 2006 11:03:18 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA7G35EM005167; Tue, 7 Nov 2006 10:03:14 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 10:03:08 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 17:03:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Re: 489 status code Date: Tue, 7 Nov 2006 17:03:05 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072BD09@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: 489 status code Thread-Index: AccCKbQ9AknnvJpFSQq6dHqX/Fd9xQAXCj6w From: "Drage, Keith \(Keith\)" To: "Marc Petit-Huguenin" X-OriginalArrivalTime: 07 Nov 2006 16:03:07.0009 (UTC) FILETIME=[36B58F10:01C70286] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, sipping@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Whatever keeps it from assigning digits. The key point is that nobody is supervising all these selections made by individual author drafts, and we even find conflicts in working group items, and therefore if someone is trying something in an implementation, they are guaranteed to get a conflict if that usage survives for any length of time. Regards Keith=20 > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 > Sent: 07 November 2006 05:00 > To: Drage, Keith (Keith) > Cc: Adam Roach; sip@ietf.org; sipping@ietf.org > Subject: Re: [Sip] Re: 489 status code >=20 > Drage, Keith (Keith) wrote: > > (As SIP WG chair) > >=20 > > See http://www.iana.org/assignments/sip-parameters for a list of=20 > > currently assigned response codes (with 489 allocated=20 > already as Adam=20 > > indicates). > >=20 > > As definition of a new response code requires a SIP WG=20 > document, can I=20 > > suggest that only such documents make any attempt to assign=20 > a response=20 > > code value - I know this can be useful because the examples have to=20 > > show it. If your document is not one of these, use 4xx or something=20 > > else that can be replaced later. >=20 > Using 4xx can be confusing as there will be no way to know if=20 > it is an yet unassigned specific response code in the 4xx=20 > class or the whole 4xx class. May I suggest 4?? instead? >=20 > >=20 > > I notice also drafts in SIPPING group attempting to assign response=20 > > codes. > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 13:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVoL-0002KO-9R; Tue, 07 Nov 2006 13:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVoK-0002HM-Hk for sip@ietf.org; Tue, 07 Nov 2006 13:36:36 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVoJ-0003n4-4Y for sip@ietf.org; Tue, 07 Nov 2006 13:36:36 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2006 10:36:35 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGNgUEVAZnme/2dsb2JhbACCcg X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208,217"; a="48144588:sNHT46435940" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7IaYDk032559; Tue, 7 Nov 2006 13:36:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7IaYYN016508; Tue, 7 Nov 2006 13:36:34 -0500 (EST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Tue, 7 Nov 2006 13:36:29 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E02534AE8@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Thread-Index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQ From: "Sanjay Sinha \(sanjsinh\)" To: "Matthew Gardiner" , X-OriginalArrivalTime: 07 Nov 2006 18:36:28.0325 (UTC) FILETIME=[A31EF550:01C7029B] DKIM-Signature: a=rsa-sha1; q=dns; l=5000; t=1162924594; x=1163788594; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:RE=3A=20[Sip]=20RFC=203261=20Ambiguous=20SIP=20URI=20table=20in=2019.1.1 |To:=22Matthew=20Gardiner=22=20, =20; X=v=3Dcisco.com=3B=20h=3DYWCQDEcVGFVIrhwRstJ7cXrhWv4=3D; b=CYcYYePScFDxi4o8ybc1CEdjDbfwry7aQC7NE9MXw6Dkj0Fuvrxlu/fGRz/JDl/eeCQhdHSR YUzzvFHOa8QI9cIKQmfodvs+4BpsIOjabjsvhdvVau3zYb29uNIsxttP; Authentication-Results: rtp-dkim-1.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1041902091==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1041902091== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7029B.A2E63398" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7029B.A2E63398 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe this is a sip-implementors questions. =20 Besides, I do not understand the question. host is only parameter in a sip url, if there are other parameters needed they can be added. For example if a sip Invite terminates on a pstn gateway, a user portion, which identifies the pstn user, will be required =20 ________________________________ From: Matthew Gardiner [mailto:Matthew.Gardiner@ACULAB.COM]=20 Sent: Tuesday, November 07, 2006 8:35 AM To: sip@ietf.org Subject: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 =09 =09 Hi,=20 I am attempting to tighten up our SIP stack's behaviour regarding which URI parameters/fields to display/hide in header fields. This quest led me to a table known as "Table 1" in section 19.1.1(?) of RFC 3261. This table seems to present whether or not fields such as port and transport are optional or mandatory in headers, such as the "Contact" header. My understanding of this table leads me to believe that the only mandatory field for all header categories is the host address - that's why an 'm' character only appears in the "host" row. So, apparently, all of the other fields are either optional or not allowed. Surely this constraint only applies when those fields have a their default value? What happens if a field assumes a non-default value, surely then the presentation of this value becomes mandatory in some header field somewhere? Could someone clarify how, if at all, this table is to be interpreted regarding non-default values for URI parameters/fields? thanks=20 Matt =20 ------_=_NextPart_001_01C7029B.A2E63398 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 3261 Ambiguous SIP URI table in 19.1.1
I believe this is a sip-implementors=20 questions.
 
Besides, I do not understand the question. host = is only=20 parameter in a sip url, if there are other parameters needed they can be = added.=20 For example if a sip Invite terminates on a pstn gateway, a user = portion, which=20 identifies the pstn user, will be required
 

From: Matthew Gardiner=20 [mailto:Matthew.Gardiner@ACULAB.COM]
Sent: Tuesday, = November 07,=20 2006 8:35 AM
To: sip@ietf.org
Subject: [Sip] RFC = 3261=20 Ambiguous SIP URI table in 19.1.1

Hi,

I am attempting to tighten up our SIP = stack's=20 behaviour regarding which URI parameters/fields to display/hide in = header=20 fields. This quest led me to a table known as "Table 1" in section = 19.1.1(?)=20 of RFC 3261. This table seems to present whether or not fields such as = port=20 and transport are optional or mandatory in headers, such as the = "Contact"=20 header. My understanding of this table leads me to believe that the = only=20 mandatory field for all header categories is the host address - that's = why an=20 'm' character only appears in the "host" row.

So, apparently, all of the other fields = are either=20 optional or not allowed. Surely this constraint only applies when = those fields=20 have a their default value? What happens if a field assumes a = non-default=20 value, surely then the presentation of this value becomes mandatory in = some=20 header field somewhere?

Could someone clarify how, if at all, = this table is=20 to be interpreted regarding non-default values for URI=20 parameters/fields?

thanks
Matt  

------_=_NextPart_001_01C7029B.A2E63398-- --===============1041902091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1041902091==-- From sip-bounces@ietf.org Tue Nov 07 14:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWhv-0004uU-Ec; Tue, 07 Nov 2006 14:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWhu-0004uL-38 for sip@ietf.org; Tue, 07 Nov 2006 14:34:02 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWhs-0002QI-KO for sip@ietf.org; Tue, 07 Nov 2006 14:34:02 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA7J2KwL006872 for ; Tue, 7 Nov 2006 21:03:39 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 21:03:08 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 21:03:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 21:03:06 +0200 Message-ID: In-Reply-To: <00D42150952F70458C66072322F7FE250B0BEF@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: a couple of informational comments Thread-Index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAJ8EWQ From: To: X-OriginalArrivalTime: 07 Nov 2006 19:03:07.0779 (UTC) FILETIME=[5C784530:01C7029F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] Outbound-05: a couple of informational comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have a couple of comments on the current Outbound draft. These have nothing to do with the normative behavior, but would be useful additions from information/motivation point of view: - Section 3.3 discusses why multiple connections are good for reliability. The main motivation there is that multiple connections to separate proxies protect against the failure of an individual proxy. An additional motivation, which is currently missing, is related to multihomed UAs. Such UAs would benefit from multiple connections from different interfaces (or IP addresses) even if there is only a single outbound proxy. This would protect against the failure of an individual access link or the path between the particular interface and the proxy. For instance it is quite realistic that in a few years there are many UAs that have both cellular wireless interface (3G, WiMAX, ...) and a WLAN interface, and whenever there is a WLAN available, they could be multihomed and have a separate SIP registration/connection from each interface. In the wireless access the risk of the access link/coverage going down is quite big, so the benefit would be real. I believe the current outbound mechanism supports this scenario already, but it would be good to explain it in Section 3.3 as another reason for doing mulitiple connections. I suppose q-values can be used to inform the proxy which connection the UA prefers (for instance the one using WLAN)? - Section 4.4 has some discussion on why some implementations/deployments might want to use a larger value for TCP keeplive timer than the default 95-120 seconds. The main reason offered is that the load on the servers might be too excessive. Another, perhaps even more pressing, reason has to do with wireless devices. In many cellular radio networks the frequent keepalive traffic will drain the battery of the devices quite fast, so they would like to send the keepalives as rarely as possible.=20 Again, the spec allows higher values (bounded by the actual NAT/FW timers, of course), so this is not a problem, but it would be good to add this consideration explicitly in the draft. If the authors and the WG see these as useful additions, I can propose some specific text for both cases. Regards, Markus=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 17:16:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZBq-0000Lw-Al; Tue, 07 Nov 2006 17:13:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZBp-0000Lr-KW for sip@ietf.org; Tue, 07 Nov 2006 17:13:05 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZBo-0005Xi-Az for sip@ietf.org; Tue, 07 Nov 2006 17:13:05 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1144600ugd for ; Tue, 07 Nov 2006 14:13:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DbK67j6mqaFmUWEwNxOqV/vkzPPa+LBnOseQdMCHIJgGnNBXpuuiyrTdrFI1c+ZvmJqsuYQgheXMkgJf0bPcJq1VBLvr6SiyLu7b1R/oYUsdipAhmb4hAO/3CiUhnesovPnoEfmI7izxq4KeUNBwojv1uJBPH9NbdMPRGhylq9Q= Received: by 10.78.178.5 with SMTP id a5mr8884815huf.1162937582513; Tue, 07 Nov 2006 14:13:02 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 7 Nov 2006 14:13:02 -0800 (PST) Message-ID: <953beacc0611071413t6239677atc5e623512c3270e8@mail.gmail.com> Date: Tue, 7 Nov 2006 14:13:02 -0800 From: "Rohan Mahy" To: "Adam Roach" Subject: Re: [Sip] Outbound and SigComp In-Reply-To: <454FE545.4050107@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <454E6189.1020002@nostrum.com> <953beacc0611061602r2303a9b4i9645327f9df22ce5@mail.gmail.com> <454FE545.4050107@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam, Fixed. It would be extraordinarily helpful if section 11 of draft-ietf-rohc-sigcomp-impl-guide actually included the term "well-known shim". thanks, -rohan On 11/6/06, Adam Roach wrote: > Rohan Mahy wrote: > > On 11/5/06, Adam Roach wrote: > >> Also, you cite the shim as coming from RFC 3320. In fact, it comes from > >> the implementors' guide, which in in WGLC: > >> draft-ietf-rohc-sigcomp-impl-guide-08.txt. > > > > actually we were both wrong. The well-known-shim is defined in: > > draft-ietf-rohc-sigcomp-sip-03.txt. > > Uh, no. > > I'm actually somewhat aware of the contents of the drafts I co-author. > > The shim is in draft-ietf-rohc-sigcomp-impl-guide-08.txt. > > Gonzalo copied it into draft-ietf-rohc-sigcomp-sip-03.txt due to some > uncertainty on his part about the status of > draft-ietf-rohc-sigcomp-impl-guide-08.txt. > > It will be removed in draft-ietf-rohc-sigcomp-sip-04.txt, never to reappear. > > You *REALLY* want to cite draft-ietf-rohc-sigcomp-impl-guide-08.txt > > I promise. > > /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 sip-bounces@ietf.org Tue Nov 07 17:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZGo-0004KS-JZ; Tue, 07 Nov 2006 17:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZGm-00048n-HV for sip@ietf.org; Tue, 07 Nov 2006 17:18:12 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZGc-0006IO-5h for sip@ietf.org; Tue, 07 Nov 2006 17:18:05 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kA7MI1TA025552 for ; Tue, 7 Nov 2006 16:18:01 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 16:18:01 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 23:17:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 7 Nov 2006 23:17:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072BDED@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP status Thread-Index: AccCupThSwP0tN4KTb69zlGN1t0lUw== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 07 Nov 2006 22:18:00.0053 (UTC) FILETIME=[959BB250:01C702BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] SIP status X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) There are a set of slides at the IETF#67 presentations site as below. http://www3.ietf.org/proceedings/06nov/slides/sip-1.pdf These are the WG chairs view of the current status of the work within the SIP WG. At the WG we will probably do no more that present the cover sheet, and ask for any questions, points of view or whatever on any of the documents covered for which agenda time has not been allocated. Therefore if you wish to understand this discussion - you will need to have looked at the slides beforehand. This has to be brief, as we need to get on to the agenda items that have been requested. Alternatively, feel free to use the mailing list. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 20:01:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbki-0003xV-LX; Tue, 07 Nov 2006 19:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbkg-0003xI-VJ for sip@ietf.org; Tue, 07 Nov 2006 19:57:14 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghbkd-0001qI-Ks for sip@ietf.org; Tue, 07 Nov 2006 19:57:14 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8D00631ZZJAF@siemenscomms.co.uk> for sip@ietf.org; Wed, 08 Nov 2006 00:57:19 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG9R6K>; Wed, 08 Nov 2006 00:57:08 +0000 Content-return: allowed Date: Wed, 08 Nov 2006 00:57:07 +0000 From: "Elwell, John" Subject: RE: [Sip] SIP status - connected-identity To: "Drage, Keith (Keith)" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A4B2F1F@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, Concerning connected-identity, there is one major issue that was not fixed in draft 02 (which otherwise has all the fixes from WGLC). There was some discussion on how to fix that and this is the sole thing I will cover during my presentation (slides will be available soon). From off-line discussions so far this week, I am hoping that the resolution will be simple, but let's see. John > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 07 November 2006 22:18 > To: sip@ietf.org > Subject: [Sip] SIP status > > (As WG chair) > > There are a set of slides at the IETF#67 presentations site as below. > > http://www3.ietf.org/proceedings/06nov/slides/sip-1.pdf > > These are the WG chairs view of the current status of the work within > the SIP WG. > > At the WG we will probably do no more that present the cover > sheet, and > ask for any questions, points of view or whatever on any of the > documents covered for which agenda time has not been allocated. > Therefore if you wish to understand this discussion - you will need to > have looked at the slides beforehand. > > This has to be brief, as we need to get on to the agenda > items that have > been requested. Alternatively, feel free to use the mailing list. > > Regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 21:34:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdCn-0004ai-RV; Tue, 07 Nov 2006 21:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdCn-0004ZN-1u for sip@ietf.org; Tue, 07 Nov 2006 21:30:21 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhdCl-0004nD-Hn for sip@ietf.org; Tue, 07 Nov 2006 21:30:21 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA82U44M030344 for ; Wed, 8 Nov 2006 04:30:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 04:30:18 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 04:30:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Updated draft-niemi-sip-subnot-etags Date: Wed, 8 Nov 2006 04:30:15 +0200 Message-ID: In-Reply-To: <454E1E69.6050703@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated draft-niemi-sip-subnot-etags Thread-Index: AccBAArdmkjB81dgQYqWBrQ/5N3MzwBz8qpg From: To: , X-OriginalArrivalTime: 08 Nov 2006 02:30:17.0901 (UTC) FILETIME=[D477FDD0:01C702DD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think this is a useful optimization for SIP events in general, and definitely needed for Presence.=20 The main problem in deploying SIP presence in wireless networks is still that the amount of traffic it generates is too large. Even if the actual state changes were infrequent, the subscription refreshes can generate a lot of traffic, as each refresh triggers a full-state NOTIFY. The partial notification mechanism in SIMPLE does not help with this, since it does not apply to refreshes. It is of course possible to increase the subcription refresh interval, but that has its tradeoffs too. And besides helping with the refreshes, this draft is helpful in polling and re-subscriptions after connectivity breaks.=20 The proposed mechanism seems relatively simple, so complexity should not be an issue. Also, as this is a backwards compatible extension with support negotiation, no-one is forced to implement it if they think it's not useful for them. So, I strongly support adopting this as a WG item. For the further work, I think it would be essential to clarify how this works with the resource list mechanism, as people would like to use the two mechanisms together.=20 Regards, Markus >-----Original Message----- >From: ext Aki Niemi [mailto:aki.niemi@nokia.com]=20 >Sent: 05 November, 2006 19:25 >To: IETF SIP List >Subject: [Sip] Updated draft-niemi-sip-subnot-etags > >Hodwy, > >Managed to squeeze in an update to the conditional subscribe draft: > >http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt > >Major changes include: > >- Bunch of clarifications and fixes contributed by Johnny Vrancken > >- Added the concept of "*" entity-tag, as suggested by=20 >Christian Schmidt > >The rationale for the latter change is that it turns out if=20 >you're suppressing NOTIFYs within the subscription, it doesn't=20 >matter what the actual value of the entity-tag is; the=20 >superfluous notifications should simply get suppressed by=20 >default. It is now possible by including > > Suppress-Notify-If-Match: * > >to the SUBSCRIBE in subscription refreshes/unsubscribes. This=20 >has some other interesting uses as well, like being able to do=20 >a HEAD like query for the current entity-tag, or a=20 >heartbeat-type function to check the liveliness of a resource=20 >(without the extra cost of receiving the notification). > >In essence, the client need not bother tracking the etags=20 >unless it is resuming a subscription, or using polling to=20 >query the state. To me, this is a simple addition that doesn't=20 >introduce any complexity, and ought to be the default behavior anyway. > >I'm planning to make a fairly extensive rewrite of this draft=20 >to make it look more like an implementation spec, including=20 >adding detailed examples and moving some of the requirements=20 >text to an appendix. > >However, before I commit to that, it would be nice to get some=20 >traction to the draft from the working group. > >Is this something the SIP WG is interested in progressing as a=20 >WG effort? > >Cheers, >Aki > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 22:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghdrv-0006f5-Cf; Tue, 07 Nov 2006 22:12:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdrI-0005jX-NU for sip@ietf.org; Tue, 07 Nov 2006 22:12:12 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghdj1-0001C0-8i for sip@ietf.org; Tue, 07 Nov 2006 22:03:43 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id kA833ScA023305; Wed, 8 Nov 2006 04:03:28 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id kA833S7M002824; Wed, 8 Nov 2006 04:03:28 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 04:03:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] Updated draft-niemi-sip-subnot-etags Date: Wed, 8 Nov 2006 04:03:26 +0100 Message-ID: <72963DDDF17D7949ABD18DC5DA58E770017D51A4@MCHP7R5A.ww002.siemens.net> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated draft-niemi-sip-subnot-etags Thread-Index: AccBAArdmkjB81dgQYqWBrQ/5N3MzwBz8qpgAARi/bA= From: "Schmidt, Christian" To: , , X-OriginalArrivalTime: 08 Nov 2006 03:03:27.0944 (UTC) FILETIME=[76A07480:01C702E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, currently, performance load caused by Presence service is very=20 difficult to predict. Any method to avoid redundant traffic (without adding much complexity and decreasing functionality) is useful. This is the case for this etag draft. Therefore I also support, to adopt this as a WG item. Regards Christian =20 -----Urspr=FCngliche Nachricht----- Von: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Gesendet: Mittwoch, 8. November 2006 03:30 An: aki.niemi@nokia.com; sip@ietf.org Betreff: RE: [Sip] Updated draft-niemi-sip-subnot-etags Hi, I think this is a useful optimization for SIP events in general, and definitely needed for Presence.=20 The main problem in deploying SIP presence in wireless networks is still that the amount of traffic it generates is too large. Even if the actual state changes were infrequent, the subscription refreshes can generate a lot of traffic, as each refresh triggers a full-state NOTIFY. The partial notification mechanism in SIMPLE does not help with this, since it does not apply to refreshes. It is of course possible to increase the subcription refresh interval, but that has its tradeoffs too. And besides helping with the refreshes, this draft is helpful in polling and re-subscriptions after connectivity breaks.=20 The proposed mechanism seems relatively simple, so complexity should not be an issue. Also, as this is a backwards compatible extension with support negotiation, no-one is forced to implement it if they think it's not useful for them. So, I strongly support adopting this as a WG item. For the further work, I think it would be essential to clarify how this works with the resource list mechanism, as people would like to use the two mechanisms together.=20 Regards, Markus >-----Original Message----- >From: ext Aki Niemi [mailto:aki.niemi@nokia.com]=20 >Sent: 05 November, 2006 19:25 >To: IETF SIP List >Subject: [Sip] Updated draft-niemi-sip-subnot-etags > >Hodwy, > >Managed to squeeze in an update to the conditional subscribe draft: > >http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt > >Major changes include: > >- Bunch of clarifications and fixes contributed by Johnny Vrancken > >- Added the concept of "*" entity-tag, as suggested by=20 >Christian Schmidt > >The rationale for the latter change is that it turns out if=20 >you're suppressing NOTIFYs within the subscription, it doesn't=20 >matter what the actual value of the entity-tag is; the=20 >superfluous notifications should simply get suppressed by=20 >default. It is now possible by including > > Suppress-Notify-If-Match: * > >to the SUBSCRIBE in subscription refreshes/unsubscribes. This=20 >has some other interesting uses as well, like being able to do=20 >a HEAD like query for the current entity-tag, or a=20 >heartbeat-type function to check the liveliness of a resource=20 >(without the extra cost of receiving the notification). > >In essence, the client need not bother tracking the etags=20 >unless it is resuming a subscription, or using polling to=20 >query the state. To me, this is a simple addition that doesn't=20 >introduce any complexity, and ought to be the default behavior anyway. > >I'm planning to make a fairly extensive rewrite of this draft=20 >to make it look more like an implementation spec, including=20 >adding detailed examples and moving some of the requirements=20 >text to an appendix. > >However, before I commit to that, it would be nice to get some=20 >traction to the draft from the working group. > >Is this something the SIP WG is interested in progressing as a=20 >WG effort? > >Cheers, >Aki > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 07 22:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe1n-0006YG-Do; Tue, 07 Nov 2006 22:23:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe1l-0006YA-HO for sip@ietf.org; Tue, 07 Nov 2006 22:23:01 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghe1k-0004NR-HJ for sip@ietf.org; Tue, 07 Nov 2006 22:23:01 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kA83MxkI159282 for ; Wed, 8 Nov 2006 03:22:59 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA83Q4mQ3268648 for ; Wed, 8 Nov 2006 04:26:04 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA83MxNK018834 for ; Wed, 8 Nov 2006 04:22:59 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA83MxJW018831; Wed, 8 Nov 2006 04:22:59 +0100 In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E770017D51A4@MCHP7R5A.ww002.siemens.net> To: aki.niemi@nokia.com, sip@ietf.org MIME-Version: 1.0 Subject: Re: AW: [Sip] Updated draft-niemi-sip-subnot-etags X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 8 Nov 2006 05:26:01 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 08/11/2006 05:26:03, Serialize complete at 08/11/2006 05:26:03 X-Spam-Score: 0.5 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1301236350==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1301236350== Content-Type: multipart/alternative; boundary="=_alternative 00129A15C2257220_=" This is a multipart message in MIME format. --=_alternative 00129A15C2257220_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Same here as I said once or twice before. See also the discussion in draft-rang-simple-problem-statement-01.txt. subnot-etags is one of the only optimizations that save both on the=20 network and on the processing load on the presence server. Thanks --Avshalom "Schmidt, Christian" =20 08/11/2006 05:03 To , , cc Subject AW: [Sip] Updated draft-niemi-sip-subnot-etags Hi, currently, performance load caused by Presence service is very=20 difficult to predict. Any method to avoid redundant traffic (without adding much complexity and decreasing functionality) is useful. This is the case for this etag draft. Therefore I also support, to adopt this as a WG item. Regards Christian =20 -----Urspr=FCngliche Nachricht----- Von: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Gesendet: Mittwoch, 8. November 2006 03:30 An: aki.niemi@nokia.com; sip@ietf.org Betreff: RE: [Sip] Updated draft-niemi-sip-subnot-etags Hi, I think this is a useful optimization for SIP events in general, and definitely needed for Presence.=20 The main problem in deploying SIP presence in wireless networks is still that the amount of traffic it generates is too large. Even if the actual state changes were infrequent, the subscription refreshes can generate a lot of traffic, as each refresh triggers a full-state NOTIFY. The partial notification mechanism in SIMPLE does not help with this, since it does not apply to refreshes. It is of course possible to increase the subcription refresh interval, but that has its tradeoffs too. And besides helping with the refreshes, this draft is helpful in polling and re-subscriptions after connectivity breaks.=20 The proposed mechanism seems relatively simple, so complexity should not be an issue. Also, as this is a backwards compatible extension with support negotiation, no-one is forced to implement it if they think it's not useful for them. So, I strongly support adopting this as a WG item. For the further work, I think it would be essential to clarify how this works with the resource list mechanism, as people would like to use the two mechanisms together.=20 Regards, Markus >-----Original Message----- >From: ext Aki Niemi [mailto:aki.niemi@nokia.com]=20 >Sent: 05 November, 2006 19:25 >To: IETF SIP List >Subject: [Sip] Updated draft-niemi-sip-subnot-etags > >Hodwy, > >Managed to squeeze in an update to the conditional subscribe draft: > >http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt > >Major changes include: > >- Bunch of clarifications and fixes contributed by Johnny Vrancken > >- Added the concept of "*" entity-tag, as suggested by=20 >Christian Schmidt > >The rationale for the latter change is that it turns out if=20 >you're suppressing NOTIFYs within the subscription, it doesn't=20 >matter what the actual value of the entity-tag is; the=20 >superfluous notifications should simply get suppressed by=20 >default. It is now possible by including > > Suppress-Notify-If-Match: * > >to the SUBSCRIBE in subscription refreshes/unsubscribes. This=20 >has some other interesting uses as well, like being able to do=20 >a HEAD like query for the current entity-tag, or a=20 >heartbeat-type function to check the liveliness of a resource=20 >(without the extra cost of receiving the notification). > >In essence, the client need not bother tracking the etags=20 >unless it is resuming a subscription, or using polling to=20 >query the state. To me, this is a simple addition that doesn't=20 >introduce any complexity, and ought to be the default behavior anyway. > >I'm planning to make a fairly extensive rewrite of this draft=20 >to make it look more like an implementation spec, including=20 >adding detailed examples and moving some of the requirements=20 >text to an appendix. > >However, before I commit to that, it would be nice to get some=20 >traction to the draft from the working group. > >Is this something the SIP WG is interested in progressing as a=20 >WG effort? > >Cheers, >Aki > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 00129A15C2257220_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Same here as I said once or twice b= efore.

See also the discussion in draft-ra= ng-simple-problem-statement-01.txt.
subnot-etags is one of the only opt= imizations that save both on the network
and on the processing load on the p= resence server.

Thanks
--Avshalom


"Schmidt, Christ= ian" <christian-schmidt@siemens.com>

08/11/2006 05:03

To
<Markus.Isomaki@nokia.com>, &l= t;aki.niemi@nokia.com>, <sip@ietf.org>
cc
Subject
AW: [Sip] Updated draft-niemi-sip-su= bnot-etags





Hi,

currently, performance load caused by Presence service is very
difficult to predict. Any method to avoid redundant traffic
(without adding much complexity and decreasing functionality)
is useful. This is the case for this etag draft. Therefore I
also support, to adopt this as a WG item.

Regards
Christian



-----Urspr=FCngliche Nachricht-----
Von: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
Gesendet: Mittwoch, 8. November 2006 03:30
An: aki.niemi@nokia.com; sip@ietf.org
Betreff: RE: [Sip] Updated draft-niemi-sip-subnot-etags

Hi,

I think this is a useful optimization for SIP events in general, and
definitely needed for Presence.

The main problem in deploying SIP presence in wireless networks is still
that the amount of traffic it generates is too large. Even if the actual
state changes were infrequent, the subscription refreshes can generate a
lot of traffic, as each refresh triggers a full-state NOTIFY. The
partial notification mechanism in SIMPLE does not help with this, since
it does not apply to refreshes. It is of course possible to increase the
subcription refresh interval, but that has its tradeoffs too. And
besides helping with the refreshes, this draft is helpful in polling and
re-subscriptions after connectivity breaks.

The proposed mechanism seems relatively simple, so complexity should not
be an issue. Also, as this is a backwards compatible extension with
support negotiation, no-one is forced to implement it if they think it's
not useful for them.

So, I strongly support adopting this as a WG item.

For the further work, I think it would be essential to clarify how this
works with the resource list mechanism, as people would like to use the
two mechanisms together.

Regards,
                Markus


>-----Original Message-----
>From: ext Aki Niemi [mailto:aki.niemi@nokia.com]
>Sent: 05 November, 2006 19:25
>To: IETF SIP List
>Subject: [Sip] Updated draft-niemi-sip-subnot-etags
>
>Hodwy,
>
>Managed to squeeze in an update to the conditional subscribe draft:
>
>http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt=
>
>Major changes include:
>
>- Bunch of clarifications and fixes contributed by Johnny Vrancken
>
>- Added the concept of "*" entity-tag, as suggested by
>Christian Schmidt
>
>The rationale for the latter change is that it turns out if
>you're suppressing NOTIFYs within the subscription, it doesn't
>matter what the actual value of the entity-tag is; the
>superfluous notifications should simply get suppressed by
>default. It is now possible by including
>
>   Suppress-Notify-If-Match: *
>
>to the SUBSCRIBE in subscription refreshes/unsubscribes. This
>has some other interesting uses as well, like being able to do
>a HEAD like query for the current entity-tag, or a
>heartbeat-type function to check the liveliness of a resource
>(without the extra cost of receiving the notification).
>
>In essence, the client need not bother tracking the etags
>unless it is resuming a subscription, or using polling to
>query the state. To me, this is a simple addition that doesn't
>introduce any complexity, and ought to be the default behavior anyway.<= br> >
>I'm planning to make a fairly extensive rewrite of this draft
>to make it look more like an implementation spec, including
>adding detailed examples and moving some of the requirements
>text to an appendix.
>
>However, before I commit to that, it would be nice to get some
>traction to the draft from the working group.
>
>Is this something the SIP WG is interested in progressing as a
>WG effort?
>
>Cheers,
>Aki
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use
>sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 00129A15C2257220_=-- --===============1301236350== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1301236350==-- From sip-bounces@ietf.org Wed Nov 08 02:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhiCq-0001of-3T; Wed, 08 Nov 2006 02:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhiCo-0001o0-4q for sip@ietf.org; Wed, 08 Nov 2006 02:50:42 -0500 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhiCj-00042Q-J5 for sip@ietf.org; Wed, 08 Nov 2006 02:50:42 -0500 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA87oY5i031025; Wed, 8 Nov 2006 08:50:34 +0100 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA87oXUL018038; Wed, 8 Nov 2006 08:50:33 +0100 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 08:50:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Updated draft-niemi-sip-subnot-etags Date: Wed, 8 Nov 2006 08:50:28 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated draft-niemi-sip-subnot-etags Thread-Index: AccBAArdmkjB81dgQYqWBrQ/5N3MzwBz8qpgAA24JBA= From: "Vrancken, Johnny" To: , , X-OriginalArrivalTime: 08 Nov 2006 07:50:30.0026 (UTC) FILETIME=[8FC99EA0:01C7030A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 I'd like to confirm my full support expressed in a former mail to adopt Aki's document as a WG item. As Markus stated, it is important to clarify how the proposed mechanism can be combined with other optimization techniques. Johnny -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: woensdag 8 november 2006 3:30 To: aki.niemi@nokia.com; sip@ietf.org Subject: RE: [Sip] Updated draft-niemi-sip-subnot-etags Hi, I think this is a useful optimization for SIP events in general, and definitely needed for Presence.=20 The main problem in deploying SIP presence in wireless networks is still that the amount of traffic it generates is too large. Even if the actual state changes were infrequent, the subscription refreshes can generate a lot of traffic, as each refresh triggers a full-state NOTIFY. The partial notification mechanism in SIMPLE does not help with this, since it does not apply to refreshes. It is of course possible to increase the subcription refresh interval, but that has its tradeoffs too. And besides helping with the refreshes, this draft is helpful in polling and re-subscriptions after connectivity breaks.=20 The proposed mechanism seems relatively simple, so complexity should not be an issue. Also, as this is a backwards compatible extension with support negotiation, no-one is forced to implement it if they think it's not useful for them. So, I strongly support adopting this as a WG item. For the further work, I think it would be essential to clarify how this works with the resource list mechanism, as people would like to use the two mechanisms together.=20 Regards, Markus >-----Original Message----- >From: ext Aki Niemi [mailto:aki.niemi@nokia.com]=20 >Sent: 05 November, 2006 19:25 >To: IETF SIP List >Subject: [Sip] Updated draft-niemi-sip-subnot-etags > >Hodwy, > >Managed to squeeze in an update to the conditional subscribe draft: > >http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt > >Major changes include: > >- Bunch of clarifications and fixes contributed by Johnny Vrancken > >- Added the concept of "*" entity-tag, as suggested by=20 >Christian Schmidt > >The rationale for the latter change is that it turns out if=20 >you're suppressing NOTIFYs within the subscription, it doesn't=20 >matter what the actual value of the entity-tag is; the=20 >superfluous notifications should simply get suppressed by=20 >default. It is now possible by including > > Suppress-Notify-If-Match: * > >to the SUBSCRIBE in subscription refreshes/unsubscribes. This=20 >has some other interesting uses as well, like being able to do=20 >a HEAD like query for the current entity-tag, or a=20 >heartbeat-type function to check the liveliness of a resource=20 >(without the extra cost of receiving the notification). > >In essence, the client need not bother tracking the etags=20 >unless it is resuming a subscription, or using polling to=20 >query the state. To me, this is a simple addition that doesn't=20 >introduce any complexity, and ought to be the default behavior anyway. > >I'm planning to make a fairly extensive rewrite of this draft=20 >to make it look more like an implementation spec, including=20 >adding detailed examples and moving some of the requirements=20 >text to an appendix. > >However, before I commit to that, it would be nice to get some=20 >traction to the draft from the working group. > >Is this something the SIP WG is interested in progressing as a=20 >WG effort? > >Cheers, >Aki > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 03:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhiP1-0000kJ-OK; Wed, 08 Nov 2006 03:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhiOz-0000k7-Pr for sip@ietf.org; Wed, 08 Nov 2006 03:03:17 -0500 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhiOy-0005vu-4w for sip@ietf.org; Wed, 08 Nov 2006 03:03:17 -0500 Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 0F9C18734C for ; Wed, 8 Nov 2006 08:03:05 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 08:03:03 -0000 Message-ID: <00D42150952F70458C66072322F7FE250B0BF3@saturn2.Aculab.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E02534AE8@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 thread-index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRA= From: "Matthew Gardiner" To: "Sanjay Sinha (sanjsinh)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0572334678==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0572334678== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7030C.511E2559" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7030C.511E2559 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is not a sip-implementors question. It concerns the accuracy of = "Table 1" on Section 19.1.11/12 of RFC 3261. Putting generalizations = aside, lets look at the intersection between "port" and "dialog = Contact/R-Route". The table says "o" for this case. =20 Does this imply that presentation of the port assignment is optional if = the port number happens to be a non-default value for the port, e.g. = 5067? I doubt it. I think if the port is NOT EQUAL 5060 (5061 tls) then = the table's value at this intersection should be "m". =20 It's my assumption that this table only describes the optionality for = these fields, such as port, when they possess their default value. I do = not think a specification should be encouraging a reader to make = assumptions. =20 It seems to me that this table is not applicable for non-default values = of the fields in the left-most column. =20 thanks Matt =20 -----Original Message----- From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] Sent: 07 November 2006 18:36 To: Matthew Gardiner; sip@ietf.org Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 I believe this is a sip-implementors questions. =20 Besides, I do not understand the question. host is only parameter in a = sip url, if there are other parameters needed they can be added. For = example if a sip Invite terminates on a pstn gateway, a user portion, = which identifies the pstn user, will be required =20 _____ =20 From: Matthew Gardiner [mailto:Matthew.Gardiner@ACULAB.COM]=20 Sent: Tuesday, November 07, 2006 8:35 AM To: sip@ietf.org Subject: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Hi,=20 I am attempting to tighten up our SIP stack's behaviour regarding which = URI parameters/fields to display/hide in header fields. This quest led = me to a table known as "Table 1" in section 19.1.1(?) of RFC 3261. This = table seems to present whether or not fields such as port and transport = are optional or mandatory in headers, such as the "Contact" header. My = understanding of this table leads me to believe that the only mandatory = field for all header categories is the host address - that's why an 'm' = character only appears in the "host" row. So, apparently, all of the other fields are either optional or not = allowed. Surely this constraint only applies when those fields have a = their default value? What happens if a field assumes a non-default = value, surely then the presentation of this value becomes mandatory in = some header field somewhere? Could someone clarify how, if at all, this table is to be interpreted = regarding non-default values for URI parameters/fields? thanks=20 Matt =20 ------_=_NextPart_001_01C7030C.511E2559 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 3261 Ambiguous SIP URI table in 19.1.1
This=20 is not a sip-implementors question. It concerns the accuracy of "Table = 1" on=20 Section 19.1.11/12 of RFC 3261. Putting generalizations aside, lets look = at the=20 intersection between "port" and "dialog Contact/R-Route". The table says = "o" for=20 this case.
 
Does=20 this imply that presentation of the port assignment is optional if the = port=20 number happens to be a non-default value for the port, e.g. 5067? I = doubt it. I=20 think if the port is NOT EQUAL 5060 (5061 tls) then the table's = value at=20 this intersection should be "m".
 
It's my assumption that this table only describes the = optionality for these fields, such as port, when they possess their = default=20 value. I do not think a specification should be encouraging a reader to = make=20 assumptions.
 
It=20 seems to me that this table is not applicable for non-default values of = the=20 fields in the left-most column.
 
thanks
Matt
 
-----Original Message-----
From: Sanjay Sinha = (sanjsinh)=20 [mailto:sanjsinh@cisco.com]
Sent: 07 November 2006=20 18:36
To: Matthew Gardiner; sip@ietf.org
Subject: = RE:=20 [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1

I believe this is a sip-implementors=20 questions.
 
Besides, I do not understand the question. = host is only=20 parameter in a sip url, if there are other parameters needed they can = be=20 added. For example if a sip Invite terminates on a pstn gateway, a = user=20 portion, which identifies the pstn user, will be = required
 

From: Matthew Gardiner=20 [mailto:Matthew.Gardiner@ACULAB.COM]
Sent: Tuesday, = November 07,=20 2006 8:35 AM
To: sip@ietf.org
Subject: [Sip] RFC = 3261=20 Ambiguous SIP URI table in 19.1.1

Hi,

I am attempting to tighten up our SIP = stack's=20 behaviour regarding which URI parameters/fields to display/hide in = header=20 fields. This quest led me to a table known as "Table 1" in section = 19.1.1(?)=20 of RFC 3261. This table seems to present whether or not fields such = as port=20 and transport are optional or mandatory in headers, such as the = "Contact"=20 header. My understanding of this table leads me to believe that the = only=20 mandatory field for all header categories is the host address - = that's why=20 an 'm' character only appears in the "host" row.

So, apparently, all of the other = fields are=20 either optional or not allowed. Surely this constraint only applies = when=20 those fields have a their default value? What happens if a field = assumes a=20 non-default value, surely then the presentation of this value = becomes=20 mandatory in some header field somewhere?

Could someone clarify how, if at all, = this table=20 is to be interpreted regarding non-default values for URI=20 parameters/fields?

thanks
Matt   =

------_=_NextPart_001_01C7030C.511E2559-- --===============0572334678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0572334678==-- From sip-bounces@ietf.org Wed Nov 08 04:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhjZi-0000aI-Pn; Wed, 08 Nov 2006 04:18:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhjZE-0000E7-O9 for sip@ietf.org; Wed, 08 Nov 2006 04:17:56 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhjMY-0007Bp-Ow for sip@ietf.org; Wed, 08 Nov 2006 04:04:57 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.685.15; Wed, 8 Nov 2006 01:04:50 -0800 Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 01:04:50 -0800 Received: from tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786); Wed, 8 Nov 2006 01:04:49 -0800 Received: from NA-EXMSG-C114.redmond.corp.microsoft.com ([157.54.62.167]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed, 8 Nov 2006 01:04:49 -0800 From: Sriram Parameswar To: "sip@ietf.org" Date: Wed, 8 Nov 2006 01:04:41 -0800 Thread-Topic: Sip Digest, Vol 31, Issue 20 Thread-Index: AccDDQRLChCVMAbYSaeVF5dADXNY4wABV0iw Message-ID: <732F15A0E7298048AD49664A0AFDDA4403F7A77487@NA-EXMSG-C114.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2006 09:04:49.0804 (UTC) FILETIME=[F205BCC0:01C70314] X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "aki.niemi@nokia.com" Subject: [Sip] RE: Sip Digest, Vol 31, Issue 20 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Given the current effort to reduce Presence traffic, this draft is a part o= f an arsenal of mechanisms. I support it becoming a work-group item. Thanks, Sriram Parameswar >-----Original Message----- >From: ext Aki Niemi [mailto:aki.niemi@nokia.com] >Sent: 05 November, 2006 19:25 >To: IETF SIP List >Subject: [Sip] Updated draft-niemi-sip-subnot-etags > >Hodwy, > >Managed to squeeze in an update to the conditional subscribe draft: > >http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt > >Major changes include: > >- Bunch of clarifications and fixes contributed by Johnny Vrancken > >- Added the concept of "*" entity-tag, as suggested by >Christian Schmidt > >The rationale for the latter change is that it turns out if >you're suppressing NOTIFYs within the subscription, it doesn't >matter what the actual value of the entity-tag is; the >superfluous notifications should simply get suppressed by >default. It is now possible by including > > Suppress-Notify-If-Match: * > >to the SUBSCRIBE in subscription refreshes/unsubscribes. This >has some other interesting uses as well, like being able to do >a HEAD like query for the current entity-tag, or a >heartbeat-type function to check the liveliness of a resource >(without the extra cost of receiving the notification). > >In essence, the client need not bother tracking the etags >unless it is resuming a subscription, or using polling to >query the state. To me, this is a simple addition that doesn't >introduce any complexity, and ought to be the default behavior anyway. > >I'm planning to make a fairly extensive rewrite of this draft >to make it look more like an implementation spec, including >adding detailed examples and moving some of the requirements >text to an appendix. > >However, before I commit to that, it would be nice to get some >traction to the draft from the working group. > >Is this something the SIP WG is interested in progressing as a >WG effort? > >Cheers, >Aki > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 05:45:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghkso-0007zO-HI; Wed, 08 Nov 2006 05:42:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghksm-0007zI-VV for sip@ietf.org; Wed, 08 Nov 2006 05:42:12 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghksl-0001c2-O7 for sip@ietf.org; Wed, 08 Nov 2006 05:42:12 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1GhksN-000092-9O; Wed, 08 Nov 2006 02:41:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 02:41:44 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC4B912C@sea02-mxc01.citel.com> In-Reply-To: <00D42150952F70458C66072322F7FE250B0BF3@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Thread-Index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4A== From: "Michael Procter" To: "Matthew Gardiner" , "Sanjay Sinha \(sanjsinh\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Matthew Gardiner [mailto:Matthew.Gardiner@ACULAB.COM]=20 > This is not a sip-implementors question. It concerns the accuracy of > "Table 1" on Section 19.1.11/12 of RFC 3261. Putting generalizations=20 > aside, lets look at the intersection between "port" and "dialog=20 > Contact/R-Route". The table says "o" for this case. =A0 > Does this imply that presentation of the port assignment is optional = if=20 > the port number happens to be a non-default value for the port, e.g. = 5067? > I doubt it. I think if the port is=A0NOT EQUAL 5060 (5061 tls) then = the=20 > table's value at this intersection should be=A0"m". No. This table only describes what forms are syntactically valid. It = is useful when writing a parser, or to answer questions of the form 'Can = I write this in that location?'. Your question is whether or not omitting a non-default port value is = semantically valid or not, to which the answer is 'No'. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 10:32:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpM3-00051J-7E; Wed, 08 Nov 2006 10:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpM1-0004ze-9A for sip@ietf.org; Wed, 08 Nov 2006 10:28:41 -0500 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhpLz-0004GP-T0 for sip@ietf.org; Wed, 08 Nov 2006 10:28:41 -0500 Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 844D48734E for ; Wed, 8 Nov 2006 15:28:37 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 15:28:37 -0000 Message-ID: <00D42150952F70458C66072322F7FE250B0BF8@saturn2.Aculab.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BC4B912C@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 thread-index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4AAKVuuw From: "Matthew Gardiner" To: "Michael Procter" , "Sanjay Sinha (sanjsinh)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > No. This table only describes what forms are syntactically valid. It = is useful when writing a parser,=20 > or to answer questions of the form 'Can I write this in that = location?'. Fair enough > Your question is whether or not omitting a non-default port value is = semantically valid or not, to which the answer is 'No'. Yes, that's right, I'm glad that someone understood my question. It's a shame, IMO, that RFC 3261 does not clarify this a little better. = For example, suppose I have received a Record-Route = "sip:192.168.2.1:5067", is it necessary to include the port = specification in the Request-URI and/or the Route-set? The answer to = that question is not inferred by the mentioned table and surrounding = text. thanks Matt=20 -----Original Message----- From: Michael Procter [mailto:michael.procter@citel.com] Sent: 08 November 2006 10:42 To: Matthew Gardiner; Sanjay Sinha (sanjsinh); sip@ietf.org Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 From: Matthew Gardiner [mailto:Matthew.Gardiner@ACULAB.COM]=20 > This is not a sip-implementors question. It concerns the accuracy of > "Table 1" on Section 19.1.11/12 of RFC 3261. Putting generalizations=20 > aside, lets look at the intersection between "port" and "dialog=20 > Contact/R-Route". The table says "o" for this case. =A0 > Does this imply that presentation of the port assignment is optional = if=20 > the port number happens to be a non-default value for the port, e.g. = 5067? > I doubt it. I think if the port is=A0NOT EQUAL 5060 (5061 tls) then = the=20 > table's value at this intersection should be=A0"m". No. This table only describes what forms are syntactically valid. It = is useful when writing a parser, or to answer questions of the form 'Can = I write this in that location?'. Your question is whether or not omitting a non-default port value is = semantically valid or not, to which the answer is 'No'. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 11:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpvd-0005ZO-B1; Wed, 08 Nov 2006 11:05:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpvb-0005ZJ-VC for sip@ietf.org; Wed, 08 Nov 2006 11:05:27 -0500 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghpva-00016r-Mm for sip@ietf.org; Wed, 08 Nov 2006 11:05:27 -0500 Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id E6A4187353 for ; Wed, 8 Nov 2006 16:05:11 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 16:05:12 -0000 Message-ID: <00D42150952F70458C66072322F7FE250B0BF9@saturn2.Aculab.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BC4B91E0@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 thread-index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4AAKVuuwAAB7QGAAAOIfIA== From: "Matthew Gardiner" To: "Michael Procter" , "Sanjay Sinha (sanjsinh)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > As a general rule, URIs should not be 'adjusted' as you work with = them. Maybe not, but their presentation to the outside world, should be in = certain contexts. That was my reason for visiting this table in the = first place. Case in point, the port and transport parameters being = disallowed in the To: and From: headers as mandated by this table. = (Still not sure why these parameters are disallowed here?). I visited this table in attempt to clarify some code in our stack, but = the result was further confusion! thanks Matt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 11:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpuu-0005Dc-1S; Wed, 08 Nov 2006 11:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpus-00053h-VE for sip@ietf.org; Wed, 08 Nov 2006 11:04:42 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghph4-0006vl-LA for sip@ietf.org; Wed, 08 Nov 2006 10:50:28 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1Ghph4-0001qy-8i; Wed, 08 Nov 2006 07:50:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 07:50:24 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC4B91E0@sea02-mxc01.citel.com> In-Reply-To: <00D42150952F70458C66072322F7FE250B0BF8@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-CorreFrom sip-bounces@ietf.org Wed Nov 08 11:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpvd-0005ZO-B1; Wed, 08 Nov 2006 11:05:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpvb-0005ZJ-VC for sip@ietf.org; Wed, 08 Nov 2006 11:05:27 -0500 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghpva-00016r-Mm for sip@ietf.org; Wed, 08 Nov 2006 11:05:27 -0500 Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id E6A4187353 for ; Wed, 8 Nov 2006 16:05:11 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 16:05:12 -0000 Message-ID: <00D42150952F70458C66072322F7FE250B0BF9@saturn2.Aculab.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BC4B91E0@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 thread-index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4AAKVuuwAAB7QGAAAOIfIA== From: "Matthew Gardiner" To: "Michael Procter" , "Sanjay Sinha (sanjsinh)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > As a general rule, URIs should not be 'adjusted' as you work with = them. Maybe not, but their presentation to the outside world, should be in = certain contexts. That was my reason for visiting this table in the = first place. Case in point, the port and transport parameters being = disallowed in the To: and From: headers as mandated by this table. = (Still not sure why these parameters are disallowed here?). I visited this table in attempt to clarify some code in our stack, but = the result was further confusion! thanks Matt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 11:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpuu-0005Dc-1S; Wed, 08 Nov 2006 11:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpus-00053h-VE for sip@ietf.org; Wed, 08 Nov 2006 11:04:42 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghph4-0006vl-LA for sip@ietf.org; Wed, 08 Nov 2006 10:50:28 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1Ghph4-0001qy-8i; Wed, 08 Nov 2006 07:50:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 07:50:24 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC4B91E0@sea02-mxc01.citel.com> In-Reply-To: <00D42150952F70458C66072322F7FE250B0BF8@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Thread-Index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4AAKVuuwAAB7QGA= From: "Michael Procter" To: "Matthew Gardiner" , "Sanjay Sinha \(sanjsinh\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Matthew Gardiner wrote: >=20 > > No. This table only describes what forms are syntactically valid. It > is useful when writing a parser, > > or to answer questions of the form 'Can I write this in that location?'. >=20 > Fair enough >=20 > > Your question is whether or not omitting a non-default port value is > semantically valid or not, to which the answer is 'No'. >=20 > Yes, that's right, I'm glad that someone understood my question. ;-) > It's a shame, IMO, that RFC 3261 does not clarify this a little better. > For example, suppose I have received a Record-Route > "sip:192.168.2.1:5067", is it necessary to include the port specification > in the Request-URI and/or the Route-set? The answer to that question is > not inferred by the mentioned table and surrounding text. RFC 3261 does clarify this, but not in that section. You might find it useful to look at Sec 19.1.4, and note that "sip:192.168.2.1:5067" is not=20 equivalent to "sip:192.168.2.1". If the URIs are not equivalent, then in some sense they refer to different entities. =20 As a general rule, URIs should not be 'adjusted' as you work with them. If you make a change that would cause the tests in sec 19.1.4 to deem the new URI not equivalent to the old URI, then you can expect interoperability problems sooner or later. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip lator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Thread-Index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4AAKVuuwAAB7QGA= From: "Michael Procter" To: "Matthew Gardiner" , "Sanjay Sinha \(sanjsinh\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Matthew Gardiner wrote: >=20 > > No. This table only describes what forms are syntactically valid. It > is useful when writing a parser, > > or to answer questions of the form 'Can I write this in that location?'. >=20 > Fair enough >=20 > > Your question is whether or not omitting a non-default port value is > semantically valid or not, to which the answer is 'No'. >=20 > Yes, that's right, I'm glad that someone understood my question. ;-) > It's a shame, IMO, that RFC 3261 does not clarify this a little better. > For example, suppose I have received a Record-Route > "sip:192.168.2.1:5067", is it necessary to include the port specification > in the Request-URI and/or the Route-set? The answer to that question is > not inferred by the mentioned table and surrounding text. RFC 3261 does clarify this, but not in that section. You might find it useful to look at Sec 19.1.4, and note that "sip:192.168.2.1:5067" is not=20 equivalent to "sip:192.168.2.1". If the URIs are not equivalent, then in some sense they refer to different entities. =20 As a general rule, URIs should not be 'adjusted' as you work with them. If you make a change that would cause the tests in sec 19.1.4 to deem the new URI not equivalent to the old URI, then you can expect interoperability problems sooner or later. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 12:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrD7-0000J8-8C; Wed, 08 Nov 2006 12:27:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrD6-0000J3-BE for sip@ietf.org; Wed, 08 Nov 2006 12:27:36 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrD5-0004S1-1a for sip@ietf.org; Wed, 08 Nov 2006 12:27:36 -0500 Received: from [130.129.68.74] (dhcp68-74.ietf67.org [130.129.68.74]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA8GVFOb023669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Nov 2006 10:31:16 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CCBA1F8-689D-4465-B133-95806D4EE049@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 8 Nov 2006 11:27:30 -0600 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Cullen Jennings , Keith Drage Subject: [Sip] Poll on interest in adopting draft-niemi-sip-subnot-etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, my mailbox is completely filled with requests begging us to sponsor this poor homeless child-draft that is apparently starving to death in some third-world blight-zone refugee camp and desperately needs our help. I didn't know Sally Struthers was active in the IETF, but I'm fairly sure I saw an infomercial on late-night TV where she too was asking for help with this draft. So lets put the question another way: Are any of you people OPPOSED to adopting draft-niemi-sip-subnot- etags as a deliverable of the SIP working group? If you don't want us to work on it, please speak up. If you do want us to work on it, SAY NOTHING, since if all you people who want us to work on it send an email, we won't get any work done because I'd be too busy filing your emails away . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 12:42:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrP8-0006GN-J0; Wed, 08 Nov 2006 12:40:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrP7-0006G7-9A for sip@ietf.org; Wed, 08 Nov 2006 12:40:01 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrP4-0006U3-UC for sip@ietf.org; Wed, 08 Nov 2006 12:40:01 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2006 09:39:59 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="340799584:sNHT56112924" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8HdwoL016145; Wed, 8 Nov 2006 09:39:58 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA8HdUbX024367; Wed, 8 Nov 2006 09:39:53 -0800 (PST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 12:39:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Date: Wed, 8 Nov 2006 12:39:31 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E02534EAF@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 Thread-Index: AccCcYwQjJLSkV+4Ru6icp7NuyYIZgAKXOxQABvSlRAABWvb4AAKVuuwAATSJWA= From: "Sanjay Sinha \(sanjsinh\)" To: "Matthew Gardiner" , "Michael Procter" , X-OriginalArrivalTime: 08 Nov 2006 17:39:32.0603 (UTC) FILETIME=[D99AE4B0:01C7035C] DKIM-Signature: a=rsa-sha1; q=dns; l=2501; t=1163007598; x=1163871598; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:RE=3A=20[Sip]=20RFC=203261=20Ambiguous=20SIP=20URI=20table=20in=2019.1.1; X=v=3Dcisco.com=3B=20h=3DVQ4bJ+frD0VkalPNbiF+KVQWcrw=3D; b=pBMbbkHKTTYw7s521hRsQ68y+xpya01GjjORct0PAbQgkAjH4MVXcyIFVhZWq0gA4/lmaON8 MADY4z9il0EiJc4QbXulqGnDQVN+h/65hRjuWTxLhsW4zZc6uBe94QaP; Authentication-Results: sj-dkim-5.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >-----Original Message----- >From: Matthew Gardiner [mailto:Matthew.Gardiner@ACULAB.COM]=20 >Sent: Wednesday, November 08, 2006 7:29 AM >To: Michael Procter; Sanjay Sinha (sanjsinh); sip@ietf.org >Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 > >> No. This table only describes what forms are syntactically=20 >valid. It=20 >> is useful when writing a parser, or to answer questions of=20 >the form 'Can I write this in that location?'. > >Fair enough > >> Your question is whether or not omitting a non-default port=20 >value is semantically valid or not, to which the answer is 'No'. > >Yes, that's right, I'm glad that someone understood my question. > >It's a shame, IMO, that RFC 3261 does not clarify this a=20 >little better. For example, suppose I have received a=20 >Record-Route "sip:192.168.2.1:5067", is it necessary to=20 >include the port specification in the Request-URI and/or the=20 >Route-set? The answer to that question is not inferred by the=20 >mentioned table and surrounding text. Maybe you are looking at the wrong place. For the example mentioned = above, to create the request-uri, you should be looking at sec. 12.2.1.1 Sanjay > >thanks >Matt=20 > > >-----Original Message----- >From: Michael Procter [mailto:michael.procter@citel.com] >Sent: 08 November 2006 10:42 >To: Matthew Gardiner; Sanjay Sinha (sanjsinh); sip@ietf.org >Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1 > > > >From: Matthew Gardiner [mailto:Matthew.Gardiner@ACULAB.COM]=20 >> This is not a sip-implementors question. It concerns the accuracy of=20 >> "Table 1" on Section 19.1.11/12 of RFC 3261. Putting generalizations=20 >> aside, lets look at the intersection between "port" and "dialog=20 >> Contact/R-Route". The table says "o" for this case. >=A0 >> Does this imply that presentation of the port assignment is optional=20 >> if the port number happens to be a non-default value for the=20 >port, e.g. 5067? >> I doubt it. I think if the port is=A0NOT EQUAL 5060 (5061 tls)=20 >then the=20 >> table's value at this intersection should be=A0"m". > >No. This table only describes what forms are syntactically=20 >valid. It is useful when writing a parser, or to answer=20 >questions of the form 'Can I write this in that location?'. > >Your question is whether or not omitting a non-default port=20 >value is semantically valid or not, to which the answer is 'No'. > >Regards, > >Michael > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 13:19:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghrtk-0004vx-R1; Wed, 08 Nov 2006 13:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghrtd-0004se-Nd for sip@ietf.org; Wed, 08 Nov 2006 13:11:34 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghrkt-0001lv-FI for sip@ietf.org; Wed, 08 Nov 2006 13:02:32 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA8I2UmC005038; Wed, 8 Nov 2006 12:02:30 -0600 (CST) Received: from [135.244.1.76] (vkg.lra.lucent.com [135.244.1.76]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kA8I2TI17323; Wed, 8 Nov 2006 12:02:29 -0600 (CST) Message-ID: <45521BB4.5020501@lucent.com> Date: Wed, 08 Nov 2006 12:02:28 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] ietf-sip-connect-reuse References: <449A7F93-9156-434A-9639-8403C946D5C6@cisco.com> In-Reply-To: <449A7F93-9156-434A-9639-8403C946D5C6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > I like section 8. Thanks. > The TCP behavior seems to contradict outbound. The authors of outbound > and reuse should get it^H^H together some time :-) I will corner you and Rohan to talk about this. > It seems that what a proxy should do when there is no alias flag is the > same as when there is an alias flag. Pretty much, except the alias flag makes the intention more explicit, and may be helpful during debugging to understand the behavior. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 15:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtqZ-0000v4-IG; Wed, 08 Nov 2006 15:16:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtqY-0000uz-6P for sip@ietf.org; Wed, 08 Nov 2006 15:16:30 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhtqV-0001yF-RN for sip@ietf.org; Wed, 08 Nov 2006 15:16:30 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA8KGMXY024113; Wed, 8 Nov 2006 14:16:22 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Nov 2006 14:16:22 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Nov 2006 21:16:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 8 Nov 2006 21:16:00 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807750B2@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll on interest in adopting draft-niemi-sip-subnot-etags Thread-Index: AccDWzNEiImDjL8xQIitNBA0F10phgAFvStQ From: "Drage, Keith \(Keith\)" To: "Dean Willis" , "IETF SIP List" X-OriginalArrivalTime: 08 Nov 2006 20:16:02.0433 (UTC) FILETIME=[B6613F10:01C70372] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Cullen Jennings Subject: [Sip] RE: Poll on interest in adopting draft-niemi-sip-subnot-etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And just to be absolutely clear. We assume that: wanting us to work on it, and the idea is so broken as to be unfixable Are incompatible and noone would want us to thrash ourselves to death going down that path. So this invitation to speak up does include any view that the idea is broken. Regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 08 November 2006 17:28 > To: IETF SIP List > Cc: Cullen Jennings; Drage, Keith (Keith) > Subject: Poll on interest in adopting draft-niemi-sip-subnot-etags >=20 >=20 > Ok, my mailbox is completely filled with requests begging us=20 > to sponsor this poor homeless child-draft that is apparently=20 > starving to death in some third-world blight-zone refugee=20 > camp and desperately needs our help. I didn't know Sally=20 > Struthers was active in the IETF, but I'm fairly sure I saw=20 > an infomercial on late-night TV where she too was asking for=20 > help with this draft. >=20 > So lets put the question another way: >=20 > Are any of you people OPPOSED to adopting=20 > draft-niemi-sip-subnot- etags as a deliverable of the SIP=20 > working group? >=20 > If you don't want us to work on it, please speak up. If you=20 > do want us to work on it, SAY NOTHING, since if all you=20 > people who want us to work on it send an email, we won't get=20 > any work done because I'd be too busy filing your emails away . . . >=20 > -- > Dean >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 16:22:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuXO-0002mF-1j; Wed, 08 Nov 2006 16:00:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuX9-0002gQ-EN for sip@ietf.org; Wed, 08 Nov 2006 16:00:32 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhuWh-0005ez-Gj for sip@ietf.org; Wed, 08 Nov 2006 16:00:31 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2006 12:59:54 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="755442019:sNHT46390856" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8KxrUI026646 for ; Wed, 8 Nov 2006 12:59:53 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA8Kxrin006181 for ; Wed, 8 Nov 2006 12:59:53 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 12:59:53 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.156]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 12:59:53 -0800 Message-Id: <4.3.2.7.2.20061108145925.02e74ee0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Nov 2006 14:59:51 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Nov 2006 20:59:53.0513 (UTC) FILETIME=[D6A03190:01C70378] DKIM-Signature: a=rsa-sha1; q=dns; l=2137; t=1163019593; x=1163883593; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Any=20desire=20to=20indicate=20who=20inserted=20location=20in=20a=20mess age?; X=v=3Dcisco.com=3B=20h=3DK2GvULP0HJYhGnOxnxqdr2M/AQI=3D; b=tLoOKZClquv3fMbBWKqKVdKvn11zmt80doNBPEI3BjFddpwJyhynPgspzx4bqngo3qsBaLPX texO0+Rwsk1s3UE4Gkk3cQ9yi5GGVSvjWRkCvcbUBlupBV1WWbgBNqJX; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] Any desire to indicate who inserted location in a message? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIP I'm working on the ABNF of the Geolocation header for SIP location conveyance, and have discovered a means of indicating which entity (currently by type) inserted the location *at*that*URI*, per URI in the header (i.e. this will be a header parameter, not a URI parameter). For example, if a SIP message includes location-by-value, the Geolocation header would have a "cid:" URI that can have a header parameter to indicate whether the original phone ( SIP UAC) inserted the by-value location, which would be different than if an intermediary server (say a SIP proxy) inserts location by-reference. Here, the Geolocation header would have a reference URI, which can indicate that a intermediary (and not the original phone) inserted the location. Here is an example in which there are two locations in a message: Geolocation: , The above header has 2 locations (one by-value, inserted by the phone) and one inserted by a proxy along the signaling path. An interesting facet of this is the ability to indicate which location the message was routed on if a message has multiple locations. I know this has been asked for over the years in both Geopriv and ECRIT. Here is what that additional header parameter could look like (notice the "message-routed-on" parameter associated with the location-by-reference): Geolocation: , This plays directly to the open issue we have had for some time in the case of more than one location within a message, answering "who inserted which location?" and "which was used to route the message?". [ BTW - I'm posting similar messages to this one on the GEOPRIV, ECRIT and SIP lists, but not doing one large cross-posting message - as this idea has to get multi-list visibility] Is this a desireable feature/function (indication)? James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 16:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghurg-0004TT-LR; Wed, 08 Nov 2006 16:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghurf-0004Sp-7N for sip@ietf.org; Wed, 08 Nov 2006 16:21:43 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghurd-0004yZ-Tg for sip@ietf.org; Wed, 08 Nov 2006 16:21:43 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2006 13:21:42 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="350940656:sNHT57197824" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8LLfEN021622 for ; Wed, 8 Nov 2006 13:21:41 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8LLfAo019842 for ; Wed, 8 Nov 2006 13:21:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:21:41 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.156]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:21:40 -0800 Message-Id: <4.3.2.7.2.20061108151114.031b6070@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Nov 2006 15:21:39 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Nov 2006 21:21:40.0893 (UTC) FILETIME=[E1E28CD0:01C7037B] DKIM-Signature: a=rsa-sha1; q=dns; l=1265; t=1163020901; x=1163884901; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Location=20Conveyance=20and=20Content-Disposition=20header; X=v=3Dcisco.com=3B=20h=3Darf7OSrO1dC1sVhCdcK5aDQf4Yo=3D; b=Bv4yHsREQ3kJCe15QZdvg5Vym3uv1jI6EOXylFkuu+Erw5APoXuwlN/O7nleKZ98neRPTn9j R+ptjjXnrnrmMmjfoL5NNYV7Z328A/L3OawaMLkqR4WoAxlMYZ608n27; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Sip] Location Conveyance and Content-Disposition header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm looking for feedback on the idea of adding text to the SIP Location Conveyance -06 ID discussing the use of a Content-Disposition header for a location received. Should this header be in a SIP message that contains location intended for the user recipient (verses a proxy that will route on the location value, in which "render" doesn't apply)? If not, the default value for the Content-Disposition header is "render" I believe. Does this need to be explicitly stated in this next rev of the doc? If "render" is not the (or an) appropriate action (meaning there may be multiple actions to take by default), which other Content-Disposition header-values should be mentioned in this doc? I've had one request for "attachment" to be offered for use if location is included in a MESSAGE request, offering the UAS user the choice not to have the received location automatically displayed, but have them have to take an action to display hte location received. Is this a valid use of the Content-Disposition header here (meaning, does it make sense to offer this scenario in the ID)? And, are there any other Content-Disposition header-values that make sense to articulate in this doc? Comments are requested James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 17:20:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvjw-0002IR-93; Wed, 08 Nov 2006 17:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvju-0002IL-QO for sip@ietf.org; Wed, 08 Nov 2006 17:17:46 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghvjt-0000HM-FX for sip@ietf.org; Wed, 08 Nov 2006 17:17:46 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Nov 2006 14:17:45 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="87454324:sNHT54003078" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8MHieD021258; Wed, 8 Nov 2006 14:17:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA8MHgip014836; Wed, 8 Nov 2006 14:17:44 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:17:43 -0800 Received: from [130.129.71.49] ([10.21.145.62]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:17:43 -0800 Message-ID: <45525787.40304@cisco.com> Date: Wed, 08 Nov 2006 17:17:43 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Updated GRUU spec - big changes References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> <86ejstld3p.fsf@raman.networkresonance.com> <953beacc0610290739r5f585c77x20c2d14af493f0a9@mail.gmail.com> In-Reply-To: <953beacc0610290739r5f585c77x20c2d14af493f0a9@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2006 22:17:43.0088 (UTC) FILETIME=[B5E8CB00:01C70383] DKIM-Signature: a=rsa-sha1; q=dns; l=1815; t=1163024264; x=1163888264; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Updated=20GRUU=20spec=20-=20big=20changes; X=v=3Dcisco.com=3B=20h=3D9J1BlY1qWrrKT9rSlWu3ddnh4Nc=3D; b=OZ1BGWFlW0uFidjxfpCmIMpURgkO84+4Brw6FSR7oIxhlFi1lr4QooOSJmDaCbaye12S7HBB UxBrbUpuk9UFP+sU8AJHW+XgwQcMBxz18O333sKB7vNchELs4MzNj5/K; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Rohan Mahy wrote: > On 10/27/06, Eric Rescorla wrote: > >> >> 2. The client explicitly controls limited-use GRUUs rather than >> >> having them issued by the server as an automatic side effect >> > yes. if I want a 5 minute validity GRUU or a week long validity GRUU >> > I can get one and refresh (or not) independently. >> > >> > I can also get a GRUU that is limited use but still tied to my AOR. >> > Possibly useful for allowing that pesky salesperson to bypass my call >> > screening for a day or two about something important. >> > >> > As for load, the UA only generates load on the server when it needs >> > something new. If the UA doesn't need any private GRUU, the server >> > doesn't need to generate one. If the UA wants a unique GRUU per-call, >> > the registrar does not need to do a full outbound-style registration >> > (making and saving flow tokens, etc.) >> >> I'm not an expert on SIP stacks, so maybe I'm missing something >> here, but doesn't JDR's new draft have a lightweight way to >> fetch a new anonymous GRUU? > > > Not that I am aware of. The registrations in GRUU-11 still require a > write to the location service. The question was on clients I thought; this is easy for clients to obtain since it requires no extra messaging or work for them. On the server side it requires no more additional write operations than is already done for a register refresh. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 08 20:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghz6H-00021P-7E; Wed, 08 Nov 2006 20:53:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghz6G-00021K-3O for sip@ietf.org; Wed, 08 Nov 2006 20:53:04 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghz6C-0001nq-OY for sip@ietf.org; Wed, 08 Nov 2006 20:53:04 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8F0060AX8CKH@siemenscomms.co.uk> for sip@ietf.org; Thu, 09 Nov 2006 01:53:00 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG02FS>; Thu, 09 Nov 2006 01:52:49 +0000 Content-return: allowed Date: Thu, 09 Nov 2006 01:52:48 +0000 From: "Elwell, John" To: Jonathan Rosenberg , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F26670A5023BF@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Sip] Comments on draft-rosenberg-sip-identity-coexistence X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Apologies if these comments have already been made. Section 1 "When the request arrives at the terminating UA, it first checks for the Identity and Identity-Info header fields. If present, the identity in the From header field is used as the caller ID." - The problem here is that if there is a B2BUA in the terminating domain, verification by the UA is likely to fail. Section 5 "Similarly, in cases where a proxy serves as a B2BUA and an ingress proxy, it MUST perform the B2BUA function after the ingress functions described here." Performing a B2BUA function will invalidate the Identity header, leading to the problem above. Section 8, Benefits: "Works in the presence of B2BUAs in the originating and terminating domains." Well, it only works in the presence of a B2BUA in the terminating domain if the UAS receives PAI and is prepared to use that in the face of an invalid Identity header. Section 8, Benefits: "Provides the cryptographic strengths of SIP identity to the terminating domain, so that mechanisms such as spam detection can be effective." OK, to the terminating domain, but not necessarily to the UAS. Also, not even to the terminating domain if there is an intermediate domain that uses a B2BUA. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 09 06:13:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7lj-0007Qj-4j; Thu, 09 Nov 2006 06:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7li-0007Qc-3O for sip@ietf.org; Thu, 09 Nov 2006 06:08:26 -0500 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi7lf-0000OK-Rb for sip@ietf.org; Thu, 09 Nov 2006 06:08:26 -0500 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Nov 2006 03:07:16 -0800 From: "Darshan Bildikar" To: Date: Thu, 9 Nov 2006 16:37:07 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AccD7zIrQ1Cwnq84SsaObMfjulUt8g== Message-ID: X-OriginalArrivalTime: 09 Nov 2006 11:07:17.0203 (UTC) FILETIME=[37D39A30:01C703EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Question on draft-ietf-sip-mib-12 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was going through this draft and it defines MIBS for SIP Method names and SIP option tags. I was wondering why there is no MIB for listing event packages defined in various RFC's as per RFC 3265? Rgds, Darshan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 09 07:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi8zJ-00026d-Sm; Thu, 09 Nov 2006 07:26:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi8zI-00026Y-A1 for sip@ietf.org; Thu, 09 Nov 2006 07:26:32 -0500 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi8zC-0007JL-2S for sip@ietf.org; Thu, 09 Nov 2006 07:26:32 -0500 Received: from [192.168.0.66] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 52C325190F for ; Thu, 9 Nov 2006 07:26:25 -0500 (EST) Message-ID: <45531ED3.2070503@pjsip.org> Date: Thu, 09 Nov 2006 12:28:03 +0000 From: Benny Prijono User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] Comments on draft-worley-sip-many-refers-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, I found your draft while looking for REFER+Replaces information, and I think it's great to have a documentation stating potential usages of REFER. But there's one thing that's still unclear to me. How the REFER recipient can distinguish whether to send request (specified in the method param of Refer-To target) *inside* or *outside* dialog context. Or for that matter, whether this is something that the REFER recipient should care about at all (I think it should). For example, sample #2.4 "Remote Hangup" seem to assume that the REFER recipient will somehow automagically match existing dialog and send the request in the context of that dialog. Has this type of usage been discussed and documented anywhere? If yes, then perhaps the document could point to some exact documentation, and perhaps explicitly clarify this kind of usage. My personal opinion is, unless there is a specific mechanism in the REFER request to instruct REFER recipient to send outgoing request in a dialog context, we should ban such uses. cheers, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 09 11:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCbq-0001hT-3t; Thu, 09 Nov 2006 11:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCbp-0001gw-DK for sip@ietf.org; Thu, 09 Nov 2006 11:18:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCbm-0002sn-SF for sip@ietf.org; Thu, 09 Nov 2006 11:18:33 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 08:16:26 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="1863356861:sNHT2430433694" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA9GGPnc012981; Thu, 9 Nov 2006 11:16:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA9GGOYJ029611; Thu, 9 Nov 2006 11:16:24 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 11:16:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on draft-ietf-sip-mib-12 Date: Thu, 9 Nov 2006 11:16:23 -0500 Message-ID: <0DEB933345E95A4083C4403CD2E7980C026EE54A@xmb-rtp-211.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-mib-12 Thread-Index: AccD7zIrQ1Cwnq84SsaObMfjulUt8gAKqleg From: "Kevin Lingle \(klingle\)" To: "Darshan Bildikar" , X-OriginalArrivalTime: 09 Nov 2006 16:16:24.0760 (UTC) FILETIME=[67083380:01C7041A] DKIM-Signature: a=rsa-sha1; q=dns; l=1223; t=1163088985; x=1163952985; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=klingle@cisco.com; z=From:=22Kevin=20Lingle=20\(klingle\)=22=20 |Subject:RE=3A=20[Sip]=20Question=20on=20draft-ietf-sip-mib-12 |Sender: |To:=22Darshan=20Bildikar=22=20, =20; X=v=3Dcisco.com=3B=20h=3Dcgks+zwAdSBn25T4L7BjVESyqI8=3D; b=KxwffQ2tV7iemnct26hrJzde9+Ysrh2zXzoKfnJCPXL4ohXiFBZ/P2EQ4jmpu1xxB8ggBRSz 1Idk0/3kv578ynImZjl/Cyv1Xp5vN8NLqRtMzQ3jXGS+ZEYwfqvxt5Pn; Authentication-Results: rtp-dkim-1; header.From=klingle@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org event package were not a consideration for the sip-mib draft work. certainly such a mib could be defined though. if it were it should be defined such that new event packages that are defined could be represented in the mib w/out having to actually alter the mib module itself (ie, don't define explicit objects for=20 each event pkg type). avoid even enumerated values. anything that would require the mib module to be updated to support a new event package.=20 kevin -----Original Message----- From: Darshan Bildikar [mailto:dbildikar@ipunity.com]=20 Sent: Thursday, November 09, 2006 6:07 AM To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-mib-12 I was going through this draft and it defines MIBS for SIP Method names and SIP option tags.=20 I was wondering why there is no MIB for listing event packages defined in various RFC's as per RFC 3265? Rgds, Darshan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 09 13:02:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEAc-0005az-KH; Thu, 09 Nov 2006 12:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEAb-0005au-KZ for sip@ietf.org; Thu, 09 Nov 2006 12:58:33 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEAa-0006V1-7P for sip@ietf.org; Thu, 09 Nov 2006 12:58:33 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kA9Hw9G9004656 for ; Thu, 9 Nov 2006 11:58:09 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 11:58:09 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 18:58:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 9 Nov 2006 18:58:06 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180775653@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for SIP session Thread-Index: AccEKJwb58N76RhSTvSfjRgyquMI9Q== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 09 Nov 2006 17:58:07.0727 (UTC) FILETIME=[9CAF0FF0:01C70428] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] Slides for SIP session X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All the slides for todays SIP session are now up at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 7 Please feel free to download these prior to the session. If you are working remotely: Session audio can be found at: http://videolab.uoregon.edu/events/ietf/ Jabber room instructions at: http://www3.ietf.org/meetings/text_conf.html with room "sip" After the session you will find the jabber logs here: http://www3.ietf.org/meetings/ietf-logs/ We are still short of a few for Friday's session. Authors if you are presenting please get these to the SIP chairs ASAP. We have remote participants. If we cannot get these in reasonable time we will force everyone to work to the same conditions (i.e. if the audience are not given the chance to get the slides, the presenter has to present without the slides!). Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 09 20:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKn0-0000Cd-JK; Thu, 09 Nov 2006 20:02:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKmy-00005P-Pa for sip@ietf.org; Thu, 09 Nov 2006 20:02:36 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKmx-0001Km-DK for sip@ietf.org; Thu, 09 Nov 2006 20:02:36 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kAA12Epk018119 for ; Thu, 9 Nov 2006 19:02:22 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 19:02:15 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Nov 2006 02:02:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 10 Nov 2006 02:02:13 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180775684@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of draft-ietf-sip-certs Thread-Index: AccEY9uV1W7xrjIGRva/xCepkgbbLQ== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 10 Nov 2006 01:02:14.0105 (UTC) FILETIME=[DBE83490:01C70463] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Status of draft-ietf-sip-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG chair) This document was recently on WGLC and has been updated to: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-02.txt In line with the comments made. We took a quick poll in the WG today and there was a significant number of people who had read the document, and all agreed that the document was ready for submission to IESG. We therefore declare this document done in the WG and will perform the PROTO writeup. Thankyou to Jason Fischl for his editing work on the document. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 10 10:37:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYOv-0001fm-5D; Fri, 10 Nov 2006 10:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYOt-0001fh-QA for sip@ietf.org; Fri, 10 Nov 2006 10:34:39 -0500 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYOs-0004N8-2f for sip@ietf.org; Fri, 10 Nov 2006 10:34:39 -0500 Received: (qmail 17336 invoked by uid 107); 10 Nov 2006 16:34:08 -0000 Received: from unknown (HELO ?172.16.14.46?) (David.Viamonte@genaker.net@172.16.14.46) by mail.genaker.net with AES256-SHA encrypted SMTP; 10 Nov 2006 16:34:08 -0000 Message-ID: <45549BFD.1010008@genaker.net> Date: Fri, 10 Nov 2006 16:34:21 +0100 From: David Viamonte User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: aki.niemi@nokia.com, sip@ietf.org Subject: Re: [Sip] Updated draft-niemi-sip-subnot-etags References: In-Reply-To: X-Spam-Score: 1.7 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641592675==" Errors-To: sip-bounces@ietf.org --===============1641592675== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

Regardless of the general thread about the draft traction, I have a technical question (suggestion) about a minor detail in this very interesting document.

The I-D defines in section 4.3 the behavior of a notifier, upon reception of a "Supress-Notify-If-Match". According to the description, there should be no difference in the "200 OK" message sent as an answer to the "SUBSCRIBE" request, regardless of the "SIP-Etag" value being equal or different to the "Supress-Notify-If-Match" value. That is: the subscription refresh works exactly the same if the etag values are equal or not, the only difference being whether the notifier will afterwards send a "NOTIFY" or not. In particular, there is no explicit need to carry a "SIP-Etag" header in the "200 OK" message issued by the notifier.

The problem I see with this is that the Watcher is not able to determine whether the "etag" was the same, or simply a subsequent "NOTIFY" message gets lost due to congestion problems.

I would propose that the text in 4.3 explicitly states that the "SIP-Etag" header be included in the "200 OK" answer to the "SUBSCRIBE" request, in case that is feasible (I've checked RFC 3903 and I don't see any issue with this). This way, a Watcher can determine, upon receiving a "200 OK", if the entity tag is the same (and thus, no additional "NOTIFY" is expected) or not (in this case, if a subsequent NOTIFY is not received shortly, the client may suspect something wrong is happenning, and act accordingly).

I think this was implicit in section 4.3, as is the case of RFC 3903 for the "mirror" use case related to PUBLISH messages, but it may be worth to still mention it explicitly (?). Perhaps the general rule is: if you receive a "(...)If-Match" header in a request, you SHOULD/MUST answer with a "SIP-Etag" header in its response, but I don't find any explicit text about this...

Sorry if I am missing anyething and/or my comment was already implicitly tackled somewhere else...

Cheers,

David

PS.- I agree that covering the RLS case in this doc would be extremely desirable, as Etags and RLS are seen as two major Presence traffic optimization mechanisms, and it would be very convenient to be able to use them together.


-----Original Message-----
From: ext Aki Niemi [mailto:aki.niemi@nokia.com] 
Sent: 05 November, 2006 19:25
To: IETF SIP List
Subject: [Sip] Updated draft-niemi-sip-subnot-etags

Hodwy,

Managed to squeeze in an update to the conditional subscribe draft:

http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt

Major changes include:

- Bunch of clarifications and fixes contributed by Johnny Vrancken

- Added the concept of "*" entity-tag, as suggested by 
Christian Schmidt

The rationale for the latter change is that it turns out if 
you're suppressing NOTIFYs within the subscription, it doesn't 
matter what the actual value of the entity-tag is; the 
superfluous notifications should simply get suppressed by 
default. It is now possible by including

  Suppress-Notify-If-Match: *

to the SUBSCRIBE in subscription refreshes/unsubscribes. This 
has some other interesting uses as well, like being able to do 
a HEAD like query for the current entity-tag, or a 
heartbeat-type function to check the liveliness of a resource 
(without the extra cost of receiving the notification).

In essence, the client need not bother tracking the etags 
unless it is resuming a subscription, or using polling to 
query the state. To me, this is a simple addition that doesn't 
introduce any complexity, and ought to be the default behavior anyway.

I'm planning to make a fairly extensive rewrite of this draft 
to make it look more like an implementation spec, including 
adding detailed examples and moving some of the requirements 
text to an appendix.

However, before I commit to that, it would be nice to get some 
traction to the draft from the working group.

Is this something the SIP WG is interested in progressing as a 
WG effort?

Cheers,
Aki

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

    

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1641592675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1641592675==-- From sip-bounces@ietf.org Fri Nov 10 12:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaRF-0003rk-UK; Fri, 10 Nov 2006 12:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaRE-0003rb-U1 for sip@ietf.org; Fri, 10 Nov 2006 12:45:12 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiaRA-0005c8-Kv for sip@ietf.org; Fri, 10 Nov 2006 12:45:12 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 1486D6C018; Fri, 10 Nov 2006 12:44:47 -0500 (EST) Subject: Re: [Sip] Location Conveyance and Content-Disposition header From: Scott Lawrence To: "James M. Polk" In-Reply-To: <4.3.2.7.2.20061108151114.031b6070@email.cisco.com> References: <4.3.2.7.2.20061108151114.031b6070@email.cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 10 Nov 2006 09:45:08 -0800 Message-Id: <1163180708.19301.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-11-08 at 15:21 -0600, James M. Polk wrote: > I'm looking for feedback on the idea of adding text to the SIP Location > Conveyance -06 ID discussing the use of a Content-Disposition header for a > location received. > > Should this header be in a SIP message that contains location intended for > the user recipient (verses a proxy that will route on the location value, > in which "render" doesn't apply)? > > If not, the default value for the Content-Disposition header is "render" I > believe. > > Does this need to be explicitly stated in this next rev of the doc? > > If "render" is not the (or an) appropriate action (meaning there may be > multiple actions to take by default), which other Content-Disposition > header-values should be mentioned in this doc? > > I've had one request for "attachment" to be offered for use if location is > included in a MESSAGE request, offering the UAS user the choice not to have > the received location automatically displayed, but have them have to take > an action to display hte location received. > > Is this a valid use of the Content-Disposition header here (meaning, does > it make sense to offer this scenario in the ID)? > > And, are there any other Content-Disposition header-values that make sense > to articulate in this doc? Whether or not to display location or anything else from the headers is completely up to the UA; it is a user interface decision. I don't think that there is any reason to include Content-Disposition at all, or say anything about it in the document. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 10 14:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicKO-000326-7R; Fri, 10 Nov 2006 14:46:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicKM-00031v-JR for sip@ietf.org; Fri, 10 Nov 2006 14:46:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicKK-0003g3-VN for sip@ietf.org; Fri, 10 Nov 2006 14:46:14 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2006 11:45:27 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="342663073:sNHT2919956638" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAAJjRJO016756; Fri, 10 Nov 2006 11:45:27 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAAJjQW4000382; Fri, 10 Nov 2006 11:45:27 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:45:26 -0800 Received: from [10.21.92.9] ([10.21.92.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:45:26 -0800 Message-ID: <4554D6D5.3070107@cisco.com> Date: Fri, 10 Nov 2006 14:45:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Sip] Location Conveyance and Content-Disposition header References: <4.3.2.7.2.20061108151114.031b6070@email.cisco.com> <1163180708.19301.30.camel@localhost.localdomain> In-Reply-To: <1163180708.19301.30.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2006 19:45:26.0417 (UTC) FILETIME=[C4DAF010:01C70500] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2890; t=1163187927; x=1164051927; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Location=20Conveyance=20and=20Content-Disposi tion=20header |Sender:=20; bh=mazIyZHQXAD8u1qE/zqTVae/4fqrL/Re9PgIfs1v5bg=; b=DUwSVkdBDu5IahXufBH+QdBVFDqpI+vp3KcgrXoyL4zQzQIU3oLDyl0eWNmiEdu3niFVRvCD iSk5FJImJbytcilUFr9IPMMyNPhHQZWItft8EqcCqce7Hh/1oJ8Yhgcv; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Scott, The existence of the Content-Disposition header implies that it has some significance. Unfortunately 3261 is quite light on explanation of what that significance it. The header was originally defined for mail, and its clearer what the significance is there. For now we are groping along trying to figure this out for sip. Consider a MESSAGE that contains a geoloc body. Should the recipient render that? Absent any indication otherwise, I suppose it probably should. Then consider a MESSAGE that contains a multipart mixed containing two text/plain bodies. Should it display both of them? If not, which one? What about a MESSAGE with a multipart with a geoloc body and a text/plain body? Display one or both? Now suppose the MESSAGE has a multipart with geoloc and text/plain, and a GeoLocation header with cid referencing the geoloc body? Does the answer depend on whether the UAS understands the GeoLocation header? There need to be some rules about how this works so that we get consistent results. Content-Disposition helps with this. In the above, the answers could all be resolved by rendering only those body parts that have a content-disposition of "render". Paul Scott Lawrence wrote: > On Wed, 2006-11-08 at 15:21 -0600, James M. Polk wrote: >> I'm looking for feedback on the idea of adding text to the SIP Location >> Conveyance -06 ID discussing the use of a Content-Disposition header for a >> location received. >> >> Should this header be in a SIP message that contains location intended for >> the user recipient (verses a proxy that will route on the location value, >> in which "render" doesn't apply)? >> >> If not, the default value for the Content-Disposition header is "render" I >> believe. >> >> Does this need to be explicitly stated in this next rev of the doc? >> >> If "render" is not the (or an) appropriate action (meaning there may be >> multiple actions to take by default), which other Content-Disposition >> header-values should be mentioned in this doc? >> >> I've had one request for "attachment" to be offered for use if location is >> included in a MESSAGE request, offering the UAS user the choice not to have >> the received location automatically displayed, but have them have to take >> an action to display hte location received. >> >> Is this a valid use of the Content-Disposition header here (meaning, does >> it make sense to offer this scenario in the ID)? >> >> And, are there any other Content-Disposition header-values that make sense >> to articulate in this doc? > > Whether or not to display location or anything else from the headers is > completely up to the UA; it is a user interface decision. > > I don't think that there is any reason to include Content-Disposition at > all, or say anything about it in the document. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 11 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gisk8-0001ky-GG; Sat, 11 Nov 2006 08:17:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gisk7-0001hb-6y for sip@ietf.org; Sat, 11 Nov 2006 08:17:55 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gisk5-0001xq-KY for sip@ietf.org; Sat, 11 Nov 2006 08:17:55 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20061111131742b1400s5m81e>; Sat, 11 Nov 2006 13:17:53 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kABDHgQg007439 for ; Sat, 11 Nov 2006 08:17:42 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kABDHfkt007435; Sat, 11 Nov 2006 08:17:41 -0500 Date: Sat, 11 Nov 2006 08:17:41 -0500 Message-Id: <200611111317.kABDHfkt007435@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1163180708.19301.30.camel@localhost.localdomain> (slawrence@pingtel.com) Subject: Re: [Sip] Location Conveyance and Content-Disposition header References: <4.3.2.7.2.20061108151114.031b6070@email.cisco.com> <1163180708.19301.30.camel@localhost.localdomain> X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-11-08 at 15:21 -0600, James M. Polk wrote: > I'm looking for feedback on the idea of adding text to the SIP Location > Conveyance -06 ID discussing the use of a Content-Disposition header for a > location received. > > Should this header be in a SIP message that contains location intended for > the user recipient (verses a proxy that will route on the location value, > in which "render" doesn't apply)? I think you're losing focus here. The question is not to prescibe how the receiving UA will process the message -- as Scott says, that's a UA design issue. The question is to ensure that the *intention* of the *sending* UA is mutually understood. An explicit or implied "Content-Disposition: render" implies that the sender wants the contained location is to be shown to the recipient. In practice, the receiving UA might not actually show it in the most default mode of operation, but that will be its decision based on its uderstanding of the recipient and the display situation. Etc. What becomes interesting is if the sending UA intends for the location not to be information to be delivered to the recipient, but to be some sort of metadata that is attached to the information to be delivered. But the text of section 20.11 of RFC 3261 makes it clear that Content-Disposition may be applied to body parts as well as to whole bodies. > I've had one request for "attachment" to be offered for use if location is > included in a MESSAGE request, offering the UAS user the choice not to have > the received location automatically displayed, but have them have to take > an action to display hte location received. "Content-Disposition: attachment" is already defined, isn't it? From: Paul Kyzivat Consider a MESSAGE that contains a geoloc body. Should the recipient render that? Absent any indication otherwise, I suppose it probably should. Given that the default is "Content-Disposition: render" (except for application/sdp), yes. Then consider a MESSAGE that contains a multipart mixed containing two text/plain bodies. Should it display both of them? If not, which one? Given that the default is "Content-Disposition: render", and the type is "multipart/mixed" rather than "multipart/alternative", yes. What about a MESSAGE with a multipart with a geoloc body and a text/plain body? Display one or both? Given that the default is "Content-Disposition: render", and the type is "multipart/mixed" rather than "multipart/alternative", yes. Now suppose the MESSAGE has a multipart with geoloc and text/plain, and a GeoLocation header with cid referencing the geoloc body? Does the answer depend on whether the UAS understands the GeoLocation header? Would it be surprising if the processing of the message depends on whether the recipient understands the GeoLocation header? Given that the default is "Content-Disposition: render", and the type is "multipart/mixed" rather than "multipart/alternative", yes. All of the above follow directly from the pre-existing meanings of Content-Disposition and Content-Type. Or am I totally missing the point? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 11 13:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixeA-0004w4-LP; Sat, 11 Nov 2006 13:32:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixe9-0004ui-Jk for sip@ietf.org; Sat, 11 Nov 2006 13:32:05 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gixe4-0007OY-Pq for sip@ietf.org; Sat, 11 Nov 2006 13:32:04 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kABIVjKP008710; Sat, 11 Nov 2006 12:31:45 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 11 Nov 2006 12:31:45 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 11 Nov 2006 19:31:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Nov 2006 19:31:42 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180775AFE@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New work: Option-tag for ICE Thread-Index: AccFv6H9ECpvgLxvRq23F0i0zUqkxg== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" , "Jonathan Rosenberg" X-OriginalArrivalTime: 11 Nov 2006 18:31:43.0715 (UTC) FILETIME=[A321EB30:01C705BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Sip] New work: Option-tag for ICE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG chair) As part of the ICE discussion in MMUSIC, it has been identified that there is a need for an option tag. RFC 3427 says that documents specifying these need to be presented to IESG by SIP. Rather than transfer the entirety of ICE back to SIP, the proposal is to create a separate draft that specifies this option tag and pursue this in SIP. I would appreciate if Jonathan would post to this list a some idea of the semantics of the new option tag. The intention of the SIP WG chairs is therefore to request the ADs to approve a new milestone in this area.=20 Therefore does anyone in the SIP WG have an issue with the creation of a new WG item that specifies such a new option-tag. This is intended to be a fairly short term activity (as ICE is regarded as pretty much finished) so please respond quickly. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwI-0000I0-MQ; Mon, 13 Nov 2006 05:21:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwG-0000Hv-Sb for sip@ietf.org; Mon, 13 Nov 2006 05:21:16 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYwF-0000T1-Dh for sip@ietf.org; Mon, 13 Nov 2006 05:21:16 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Pm015019; Mon, 13 Nov 2006 04:21:14 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:02 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Date: Mon, 13 Nov 2006 11:20:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5933@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Thread-Index: AccBPof3kyEDqgQpSeCK3gQqpAfjKgEsNpMw From: "Drage, Keith \(Keith\)" To: "Shida Schubert" X-OriginalArrivalTime: 13 Nov 2006 10:20:59.0392 (UTC) FILETIME=[69C64800:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Having talked directly to Shida. I obviously need to expand this bit somewhat as it seems to have led to more confusion that understanding. The key idea is that at any one time only the RFC and one correction RFC will exist - we do not directly update the original RFC as that would lead us into a complete revision which would probably last as long as the transition from RFC 2543 to RFC 3261. The idea of allowing individual or related errors to be put into separate drafts was to allow the less controversial ones to progress independently of the more controversial ones which would require more discussion. Thus I think it is still a good idea to do this although we do have to be pragmatic and essentially make sure we split for the above reason, rather than for the purpose of creating as many drafts as possible. One of the concerns of Shida was that all revisions would be identified even before they become compiled into correction RFCs. I think we can use the softarmor website to identify these, and also it would probably help to include some special part of the draft naming to indicate this. Regards Keith =20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 06 November 2006 00:57 > To: Drage, Keith (Keith) > Cc: Jonathan Rosenberg; SIP > Subject: Re: [Sip] Request for views on=20 > draft-drage-sip-essential-correction-00.txt >=20 >=20 > I generally agree with Jonathan here. I don't think we=20 > should produce a document per error. Rather, can't we take an=20 > approach that we are considering for the hitch-hiker's guide?=20 > Where a single document will be updated at certain frequency.=20 > I think from the people looking for these information it is=20 > importFrom sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwI-0000I0-MQ; Mon, 13 Nov 2006 05:21:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwG-0000Hv-Sb for sip@ietf.org; Mon, 13 Nov 2006 05:21:16 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYwF-0000T1-Dh for sip@ietf.org; Mon, 13 Nov 2006 05:21:16 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Pm015019; Mon, 13 Nov 2006 04:21:14 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:02 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Date: Mon, 13 Nov 2006 11:20:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5933@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Thread-Index: AccBPof3kyEDqgQpSeCK3gQqpAfjKgEsNpMw From: "Drage, Keith \(Keith\)" To: "Shida Schubert" X-OriginalArrivalTime: 13 Nov 2006 10:20:59.0392 (UTC) FILETIME=[69C64800:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Having talked directly to Shida. I obviously need to expand this bit somewhat as it seems to have led to more confusion that understanding. The key idea is that at any one time only the RFC and one correction RFC will exist - we do not directly update the original RFC as that would lead us into a complete revision which would probably last as long as the transition from RFC 2543 to RFC 3261. The idea of allowing individual or related errors to be put into separate drafts was to allow the less controversial ones to progress independently of the more controversial ones which would require more discussion. Thus I think it is still a good idea to do this although we do have to be pragmatic and essentially make sure we split for the above reason, rather than for the purpose of creating as many drafts as possible. One of the concerns of Shida was that all revisions would be identified even before they become compiled into correction RFCs. I think we can use the softarmor website to identify these, and also it would probably help to include some special part of the draft naming to indicate this. Regards Keith =20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 06 November 2006 00:57 > To: Drage, Keith (Keith) > Cc: Jonathan Rosenberg; SIP > Subject: Re: [Sip] Request for views on=20 > draft-drage-sip-essential-correction-00.txt >=20 >=20 > I generally agree with Jonathan here. I don't think we=20 > should produce a document per error. Rather, can't we take an=20 > approach that we are considering for the hitch-hiker's guide?=20 > Where a single document will be updated at certain frequency.=20 > I think from the people looking for these information it is=20 > important that one can find all the errors and potential=20 > fixes in one place. > Another approach is to have the document produced in the way=20 > it is mentioned in the draft but have another document that=20 > references all the fixes in a similar fashion that=20 > hitch-hiker's guide does for all the core-SIP related RFC/drafts. >=20 > Regards > Shida >=20 >=20 > Drage, Keith (Keith) wrote: > > Thanks for the comments. > > > > Inline below:=20 > > > > Regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: 01 November 2006 22:02 > >> To: Drage, Keith (Keith) > >> Cc: SIP > >> Subject: Re: [Sip] Request for views on=20 > >> draft-drage-sip-essential-correction-00.txt > >> > >> Keith, > >> > >> I agree with the final step here, but I'm not so sure about your=20 > >> details of the intermediate steps. > >> > >> In particular, I think it is too onerous to require one I-D per=20 > >> issue. > >> FOr example it would be nice for someone to go through the=20 > bugzilla=20 > >> database and submit one I-D with all of the things in it=20 > that we need=20 > >> to put into the corrections spec. THis is more palatable=20 > than having=20 > >> to submit 30 separate documents, each 6 pages in length (5.5 pages=20 > >> overhead and 1/2 page for the useful content). > >> =20 > > > > I think flexibility is needed here. Grouping of related=20 > issues, are a=20 > > number of well understood and non-controversial (but otherwise > > essential) corrections is probably OK. > > > > What we don't want to do is group things that require lots of=20 > > discussion time in the WG (SIPS fixes?) with those that=20 > don't. Nor do=20 > > we want to present two issues together such that one confuses the=20 > > understanding and WG discussion of the other. > > =20 > >> Also we need to discuss what happens when more bugs get reported=20 > >> after the correction RFC is published. DO we revise that RFC? Or=20 > >> issue another corrections document? > >> > >> =20 > > The idea was that the reader only need read the original RFC plus 1=20 > > correction RFC. Thus as more corrections are discovered, we=20 > take the=20 > > contents of the original correction RFC, the new fixes, and=20 > produce a=20 > > new RFC that obsoletes the first correction RFC, but which still=20 > > updates the original RFC. Remember however that the draft=20 > replacement=20 > > correction RFC can still be rapidly put together - and it=20 > only needs=20 > > IESG review and approval, as all the individual components=20 > have been=20 > > WGLC separately. Therefore I see this process as being reasonably=20 > > quick (in IETF terms). > > > > Note that in terms of the normal RFC process we would lose the=20 > > correction RFC if we ever take any SIP documents from proposed=20 > > standard to draft standard, i.e. the proposed standard RFC would=20 > > obsolete the > > > > =20 > >> -Jonathan R. > >> > >> Drage, Keith (Keith) wrote: > >> > >> =20 > >>> I have recently submitted > >>> > >>> > >>> =20 > >>=20 > http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correct > >> i > >> =20 > >>> on > >>> -00.txt > >>> > >>> The idea behind this draft, is to put some management=20 > into getting=20 > >>> real > >>> bugfixes: > >>> > >>> - into one place where people can find it > >>> - give it standards track RFC status so that people know they have > >>> to implement it. > >>> > >>> If people not already consulted have views on this process, then=20 > >>> please let them be known. > >>> > >>> The idea would be to start this process (taking into > >>> =20 > >> account any input > >> =20 > >>> from the WG) after the next IETF meeting. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>> Keith Drage > >>> drage@lucent.com > >>> tel: +44 1793 776249 > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwI-0000I0-MQ; Mon, 13 Nov 2006 05:21:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwG-0000Hv-Sb for sip@ietf.org; Mon, 13 Nov 2006 05:21:16 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYwF-0000T1-Dh for sip@ietf.org; Mon, 13 Nov 2006 05:21:16 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Pm015019; Mon, 13 Nov 2006 04:21:14 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:02 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Date: Mon, 13 Nov 2006 11:20:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5933@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt Thread-Index: AccBPof3kyEDqgQpSeCK3gQqpAfjKgEsNpMw From: "Drage, Keith \(Keith\)" To: "Shida Schubert" X-OriginalArrivalTime: 13 Nov 2006 10:20:59.0392 (UTC) FILETIME=[69C64800:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Having talked directly to Shida. I obviously need to expand this bit somewhat as it seems to have led to more confusion that understanding. The key idea is that at any one time only the RFC and one correction RFC will exist - we do not directly update the original RFC as that would lead us into a complete revision which would probably last as long as the transition from RFC 2543 to RFC 3261. The idea of allowing individual or related errors to be put into separate drafts was to allow the less controversial ones to progress independently of the more controversial ones which would require more discussion. Thus I think it is still a good idea to do this although we do have to be pragmatic and essentially make sure we split for the above reason, rather than for the purpose of creating as many drafts as possible. One of the concerns of Shida was that all revisions would be identified even before they become compiled into correction RFCs. I think we can use the softarmor website to identify these, and also it would probably help to include some special part of the draft naming to indicate this. Regards Keith =20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 06 November 2006 00:57 > To: Drage, Keith (Keith) > Cc: Jonathan Rosenberg; SIP > Subject: Re: [Sip] Request for views on=20 > draft-drage-sip-essential-correction-00.txt >=20 >=20 > I generally agree with Jonathan here. I don't think we=20 > should produce a document per error. Rather, can't we take an=20 > approach that we are considering for the hitch-hiker's guide?=20 > Where a single document will be updated at certain frequency.=20 > I think from the people looking for these information it is=20 > importfor questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >>> =20 > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ=20 > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > >> =20 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > > > > > =20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwA-0000A4-Ta; Mon, 13 Nov 2006 05:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYw9-00005D-39 for sip@ietf.org; Mon, 13 Nov 2006 05:21:09 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYw7-0000S8-PZ for sip@ietf.org; Mon, 13 Nov 2006 05:21:09 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Pg015019; Mon, 13 Nov 2006 04:21:00 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:00 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D on handling large UDP responses Date: Mon, 13 Nov 2006 11:20:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: Acbnbnypi7VqhST5TKezBcPeK4v/tQAdqWTwB4CWzVA= From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 13 Nov 2006 10:20:58.0611 (UTC) FILETIME=[694F1C30:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Question repeat, as it does not seem to have been answered. Regards Keith=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 04 October 2006 19:46 > To: Cullen Jennings; Dean Willis > Cc: IETF SIP List; Vijay K. Gurbani > Subject: RE: [Sip] I-D on handling large UDP responses >=20 > Can you tell us what you agreed on. The proceedings seem to=20 > have missed it, and I don't remember it appearing on the list. >=20 > Regards >=20 > Keith >=20 > > -----Original Messageant that one can find all the errors and potential=20 > fixes in one place. > Another approach is to have the document produced in the way=20 > it is mentioned in the draft but have another document that=20 > references all the fixes in a similar fashion that=20 > hitch-hiker's guide does for all the core-SIP related RFC/drafts. >=20 > Regards > Shida >=20 >=20 > Drage, Keith (Keith) wrote: > > Thanks for the comments. > > > > Inline below:=20 > > > > Regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: 01 November 2006 22:02 > >> To: Drage, Keith (Keith) > >> Cc: SIP > >> Subject: Re: [Sip] Request for views on=20 > >> draft-drage-sip-essential-correction-00.txt > >> > >> Keith, > >> > >> I agree with the final step here, but I'm not so sure about your=20 > >> details of the intermediate steps. > >> > >> In particular, I think it is too onerous to require one I-D per=20 > >> issue. > >> FOr example it would be nice for someone to go through the=20 > bugzilla=20 > >> database and submit one I-D with all of the things in it=20 > that we need=20 > >> to put into the corrections spec. THis is more palatable=20 > than having=20 > >> to submit 30 separate documents, each 6 pages in length (5.5 pages=20 > >> overhead and 1/2 page for the useful content). > >> =20 > > > > I think flexibility is needed here. Grouping of related=20 > issues, are a=20 > > number of well understood and non-controversial (but otherwise > > essential) corrections is probably OK. > > > > What we don't want to do is group things that require lots of=20 > > discussion time in the WG (SIPS fixes?) with those that=20 > don't. Nor do=20 > > we want to present two issues together such that one confuses the=20 > > understanding and WG discussion of the other. > > =20 > >> Also we need to discuss what happens when more bugs get reported=20 > >> after the correction RFC is published. DO we revise that RFC? Or=20 > >> issue another corrections document? > >> > >> =20 > > The idea was that the reader only need read the original RFC plus 1=20 > > correction RFC. Thus as more corrections are discovered, we=20 > take the=20 > > contents of the original correction RFC, the new fixes, and=20 > produce a=20 > > new RFC that obsoletes the first correction RFC, but which still=20 > > updates the original RFC. Remember however that the draft=20 > replacement=20 > > correction RFC can still be rapidly put together - and it=20 > only needs=20 > > IESG review and approval, as all the individual components=20 > have been=20 > > WGLC separately. Therefore I see this process as being reasonably=20 > > quick (in IETF terms). > > > > Note that in terms of the normal RFC process we would lose the=20 > > correction RFC if we ever take any SIP documents from proposed=20 > > standard to draft standard, i.e. the proposed standard RFC would=20 > > obsolete the > > > > =20 > >> -Jonathan R. > >> > >> Drage, Keith (Keith) wrote: > >> > >> =20 > >>> I have recently submitted > >>> > >>> > >>> =20 > >>=20 > http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correct > >> i > >> =20 > >>> on > >>> -00.txt > >>> > >>> The idea behind this draft, is to put some management=20 > into getting=20 > >>> real > >>> bugfixes: > >>> > >>> - into one place where people can find it > >>> - give it standards track RFC status so that people know they have > >>> to implement it. > >>> > >>> If people not already consulted have views on this process, then=20 > >>> please let them be known. > >>> > >>> The idea would be to start this process (taking into > >>> =20 > >> account any input > >> =20 > >>> from the WG) after the next IETF meeting. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>> Keith Drage > >>> drage@lucent.com > >>> tel: +44 1793 776249 > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu ----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 04 October 2006 05:32 > > To: Dean Willis > > Cc: IETF SIP List; Vijay K. Gurbani > > Subject: Re: [Sip] I-D on handling large UDP responses > >=20 > >=20 > > On Oct 3, 2006, at 12:01 PM, Dean Willis wrote: > >=20 > > > So, are we stuck on advancing the hop-limit-diagnostics > > draft until we > > > advance something like this draft? > >=20 > > At the last IETF, I think Vijay, Scott and I had come up=20 > with a way to=20 > > deal with hop-limit-diag without doing this but I have no=20 > objections=20 > > if folks want to have it wait for something like this. > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwK-0000Ih-FP; Mon, 13 Nov 2006 05:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwI-0000I9-Nq for sip@ietf.org; Mon, 13 Nov 2006 05:21:18 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYwH-0000TX-FR for sip@ietf.org; Mon, 13 Nov 2006 05:21:18 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Q0015019 for ; Mon, 13 Nov 2006 04:21:17 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:05 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:21:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Nov 2006 11:21:00 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B593A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UA loose route Thread-Index: AccGJwORlWi/6TwSRPGlpCGI0hcRBw== From: "Drage, Keith \(Keith\)" To: "SIP" X-OriginalArrivalTime: 13 Nov 2006 10:21:00.0924 (UTC) FILETIME=[6AB00BC0:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] UA loose route X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) At the SIP WG meeting we agreed that - there was interest in the WG in developing a deliverable addressing the issue of providing the UA with the original Request-URI as well as the Contact used to reach that user; - that draft-rosenberg-sip-ua-looseant that one can find all the errors and potential=20 > fixes in one place. > Another approach is to have the document produced in the way=20 > it is mentioned in the draft but have another document that=20 > references all the fixes in a similar fashion that=20 > hitch-hiker's guide does for all the core-SIP related RFC/drafts. >=20 > Regards > Shida >=20 >=20 > Drage, Keith (Keith) wrote: > > Thanks for the comments. > > > > Inline below:=20 > > > > Regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: 01 November 2006 22:02 > >> To: Drage, Keith (Keith) > >> Cc: SIP > >> Subject: Re: [Sip] Request for views on=20 > >> draft-drage-sip-essential-correction-00.txt > >> > >> Keith, > >> > >> I agree with the final step here, but I'm not so sure about your=20 > >> details of the intermediate steps. > >> > >> In particular, I think it is too onerous to require one I-D per=20 > >> issue. > >> FOr example it would be nice for someone to go through the=20 > bugzilla=20 > >> database and submit one I-D with all of the things in it=20 > that we need=20 > >> to put into the corrections spec. THis is more palatable=20 > than having=20 > >> to submit 30 separate documents, each 6 pages in length (5.5 pages=20 > >> overhead and 1/2 page for the useful content). > >> =20 > > > > I think flexibility is needed here. Grouping of related=20 > issues, are a=20 > > number of well understood and non-controversial (but otherwise > > essential) corrections is probably OK. > > > > What we don't want to do is group things that require lots of=20 > > discussion time in the WG (SIPS fixes?) with those that=20 > don't. Nor do=20 > > we want to present two issues together such that one confuses the=20 > > understanding and WG discussion of the other. > > =20 > >> Also we need to discuss what happens when more bugs get reported=20 > >> after the correction RFC is published. DO we revise that RFC? Or=20 > >> issue another corrections document? > >> > >> =20 > > The idea was that the reader only need read the original RFC plus 1=20 > > correction RFC. Thus as more corrections are discovered, we=20 > take the=20 > > contents of the original correction RFC, the new fixes, and=20 > produce a=20 > > new RFC that obsoletes the first correction RFC, but which still=20 > > updates the original RFC. Remember however that the draft=20 > replacement=20 > > correction RFC can still be rapidly put together - and it=20 > only needs=20 > > IESG review and approval, as all the individual components=20 > have been=20 > > WGLC separately. Therefore I see this process as being reasonably=20 > > quick (in IETF terms). > > > > Note that in terms of the normal RFC process we would lose the=20 > > correction RFC if we ever take any SIP documents from proposed=20 > > standard to draft standard, i.e. the proposed standard RFC would=20 > > obsolete the > > > > =20 > >> -Jonathan R. > >> > >> Drage, Keith (Keith) wrote: > >> > >> =20 > >>> I have recently submitted > >>> > >>> > >>> =20 > >>=20 > http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correct > >> i > >> =20 > >>> on > >>> -00.txt > >>> > >>> The idea behind this draft, is to put some management=20 > into getting=20 > >>> real > >>> bugfixes: > >>> > >>> - into one place where people can find it > >>> - give it standards track RFC status so that people know they have > >>> to implement it. > >>> > >>> If people not already consulted have views on this process, then=20 > >>> please let them be known. > >>> > >>> The idea would be to start this process (taking into > >>> =20 > >> account any input > >> =20 > >>> from the WG) after the next IETF meeting. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>> Keith Drage > >>> drage@lucent.com > >>> tel: +44 1793 776249 > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >>> =20 > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ=20 > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > >> =20 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > > > > > =20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwA-0000A4-Ta; Mon, 13 Nov 2006 05:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYw9-00005D-39 for sip@ietf.org; Mon, 13 Nov 2006 05:21:09 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYw7-0000S8-PZ for sip@ietf.org; Mon, 13 Nov 2006 05:21:09 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Pg015019; Mon, 13 Nov 2006 04:21:00 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:00 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D on handling large UDP responses Date: Mon, 13 Nov 2006 11:20:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: Acbnbnypi7VqhST5TKezBcPeK4v/tQAdqWTwB4CWzVA= From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 13 Nov 2006 10:20:58.0611 (UTC) FILETIME=[694F1C30:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Question repeat, as it does not seem to have been answered. Regards Keith=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 04 October 2006 19:46 > To: Cullen Jennings; Dean Willis > Cc: IETF SIP List; Vijay K. Gurbani > Subject: RE: [Sip] I-D on handling large UDP responses >=20 > Can you tell us what you agreed on. The proceedings seem to=20 > have missed it, and I don't remember it appearing on the list. >=20 > Regards >=20 > Keith >=20 > > -----Original Messagefor questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >>> =20 > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ=20 > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > >> =20 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > > > > > =20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwA-0000A4-Ta; Mon, 13 Nov 2006 05:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYw9-00005D-39 for sip@ietf.org; Mon, 13 Nov 2006 05:21:09 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYw7-0000S8-PZ for sip@ietf.org; Mon, 13 Nov 2006 05:21:09 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Pg015019; Mon, 13 Nov 2006 04:21:00 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:00 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D on handling large UDP responses Date: Mon, 13 Nov 2006 11:20:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: Acbnbnypi7VqhST5TKezBcPeK4v/tQAdqWTwB4CWzVA= From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 13 Nov 2006 10:20:58.0611 (UTC) FILETIME=[694F1C30:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Question repeat, as it does not seem to have been answered. Regards Keith=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 04 October 2006 19:46 > To: Cullen Jennings; Dean Willis > Cc: IETF SIP List; Vijay K. Gurbani > Subject: RE: [Sip] I-D on handling large UDP responses >=20 > Can you tell us what you agreed on. The proceedings seem to=20 > have missed it, and I don't remember it appearing on the list. >=20 > Regards >=20 > Keith >=20 > > -----Original Message-route-00 provides the basis of a mechanism for solving the above issue. The above mechanism provides an alternative to the GRID mechanism that has recently been removed from the GRUU draft. It has previously been agreed that solutions in this space are orthogonal to GRUU. The mechanism provides capabilities in its own right, GRUU provides capabilities in its own right, other capabilities can be obtained by using the two extensions together. During the meeting it was stressed that any documented solution had to take into account backward compatibility (as if we don't already). This message is to allow anyone on the mailing list who has issues with the above decisions to post them. Otherwise we will approach the Area Directors for the required charter update to include appropriate milestones. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 04 October 2006 05:32 > > To: Dean Willis > > Cc: IETF SIP List; Vijay K. Gurbani > > Subject: Re: [Sip] I-D on handling large UDP responses > >=20 > >=20 > > On Oct 3, 2006, at 12:01 PM, Dean Willis wrote: > >=20 > > > So, are we stuck on advancing the hop-limit-diagnostics > > draft until we > > > advance something like this draft? > >=20 > > At the last IETF, I think Vijay, Scott and I had come up=20 > with a way to=20 > > deal with hop-limit-diag without doing this but I have no=20 > objections=20 > > if folks want to have it wait for something like this. > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwK-0000Ih-FP; Mon, 13 Nov 2006 05:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwI-0000I9-Nq for sip@ietf.org; Mon, 13 Nov 2006 05:21:18 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYwH-0000TX-FR for sip@ietf.org; Mon, 13 Nov 2006 05:21:18 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Q0015019 for ; Mon, 13 Nov 2006 04:21:17 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:05 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:21:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Nov 2006 11:21:00 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B593A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UA loose route Thread-Index: AccGJwORlWi/6TwSRPGlpCGI0hcRBw== From: "Drage, Keith \(Keith\)" To: "SIP" X-OriginalArrivalTime: 13 Nov 2006 10:21:00.0924 (UTC) FILETIME=[6AB00BC0:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] UA loose route X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) At the SIP WG meeting we agreed that - there was interest in the WG in developing a deliverable addressing the issue of providing the UA with the original Request-URI as well as the Contact used to reach that user; - that draft-rosenberg-sip-ua-loose-route-00 provides the basis of a mechanism for solving the above issue. The above mechanism provides an alternative to the GRID mechanism that has recently been removed from the GRUU draft. It has previously been agreed that solutions in this space are orthogonal to GRUU. The mechanism provides capabilities in its own right, GRUU provides capabilities in its own right, other capabilities can be obtained by using the two extensions together. During the meeting it was stressed that any documented solution had to take into account backward compatibility (as if we don't already). This message is to allow anyone on the mailing list who has issues with the above decisions to post them. Otherwise we will approach the Area Directors for the required charter update to include appropriate milestones. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 04 October 2006 05:32 > > To: Dean Willis > > Cc: IETF SIP List; Vijay K. Gurbani > > Subject: Re: [Sip] I-D on handling large UDP responses > >=20 > >=20 > > On Oct 3, 2006, at 12:01 PM, Dean Willis wrote: > >=20 > > > So, are we stuck on advancing the hop-limit-diagnostics > > draft until we > > > advance something like this draft? > >=20 > > At the last IETF, I think Vijay, Scott and I had come up=20 > with a way to=20 > > deal with hop-limit-diag without doing this but I have no=20 > objections=20 > > if folks want to have it wait for something like this. > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwK-0000Ih-FP; Mon, 13 Nov 2006 05:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYwI-0000I9-Nq for sip@ietf.org; Mon, 13 Nov 2006 05:21:18 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYwH-0000TX-FR for sip@ietf.org; Mon, 13 Nov 2006 05:21:18 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAL0Q0015019 for ; Mon, 13 Nov 2006 04:21:17 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:21:05 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:21:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Nov 2006 11:21:00 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B593A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UA loose route Thread-Index: AccGJwORlWi/6TwSRPGlpCGI0hcRBw== From: "Drage, Keith \(Keith\)" To: "SIP" X-OriginalArrivalTime: 13 Nov 2006 10:21:00.0924 (UTC) FILETIME=[6AB00BC0:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] UA loose route X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) At the SIP WG meeting we agreed that - there was interest in the WG in developing a deliverable addressing the issue of providing the UA with the original Request-URI as well as the Contact used to reach that user; - that draft-rosenberg-sip-ua-loose-route-00 provides the basis of a mechanism for solving the above issue. The above mechanism provides an alternative to the GRID mechanism that has recently been removed from the GRUU draft. It has previously been agreed that solutions in this space are orthogonal to GRUU. The mechanism provides capabilities in its own right, GRUU provides capabilities in its own right, other capabilities can be obtained by using the two extensions together. During the meeting it was stressed that any documented solution had to take into account backward compatibility (as if we don't already). This message is to allow anyone on the mailing list who has issues with the above decisions to post them. Otherwise we will approach the Area Directors for the required charter update to include appropriate milestones. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 05:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYw6-0008Ot-0e; Mon, 13 Nov 2006 05:21:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYw4-0008Ol-Aj for sip@ietf.org; Mon, 13 Nov 2006 05:21:04 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYw0-0000Qw-0C for sip@ietf.org; Mon, 13 Nov 2006 05:21:04 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kADAKxnF014999 for ; Mon, 13 Nov 2006 04:20:59 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 04:20:59 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Nov 2006 11:20:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Nov 2006 11:20:57 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revison of WGLC on draft-ietf-sip-gruu Thread-Index: AccF5V6D7ES5V05OSYaedrrus0umyw== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 13 Nov 2006 10:20:57.0971 (UTC) FILETIME=[68ED7430:01C7070D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Revison of WGLC on draft-ietf-sip-gruu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) This is to announce a revised working group last call on draft-ietf-sip-gruu-11, which may be found at: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-11.txt This WGLC will end on Monday 27th November. Please mail all comments to the SIP list and to the authors. The comments from the previous WGLC may all be found at: https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.htm=20 Or alternatively https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.doc I would ask all who submitted comments against draft-ietf-sip-gruu-10 to check the resultion of their comments and if appropriate remake any comments they consider were not resolved to their satisfaction. Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 11:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjemK-0007Uv-BC; Mon, 13 Nov 2006 11:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjemI-0007Uf-RA for sip@ietf.org; Mon, 13 Nov 2006 11:35:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjemH-0002yQ-Ay for sip@ietf.org; Mon, 13 Nov 2006 11:35:22 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Nov 2006 08:35:21 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="449375466:sNHT61074072" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kADGZKYt009710; Mon, 13 Nov 2006 08:35:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kADGZ4j0015747; Mon, 13 Nov 2006 08:35:20 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:35:13 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:35:12 -0500 Message-ID: <45589EC0.7090005@cisco.com> Date: Mon, 13 Nov 2006 11:35:12 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] Location Conveyance and Content-Disposition header References: <4.3.2.7.2.20061108151114.031b6070@email.cisco.com> <1163180708.19301.30.camel@localhost.localdomain> <200611111317.kABDHfkt007435@dragon.ariadne.com> In-Reply-To: <200611111317.kABDHfkt007435@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 16:35:12.0961 (UTC) FILETIME=[B1250310:01C70741] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4473; t=1163435720; x=1164299720; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Location=20Conveyance=20and=20Content-Disposi tion=20header |Sender:=20; bh=t8JMulsB/qrQsyQorgHmSAY8V7bQDMuhkPAD3nBq+94=; b=rr+RHfOQOU231MZBr/HkNnzYuSxEtoKdYIre8qkTD+Iaydh1YLf0VeqpZxsly9h9pAMFwS29 kxqzZ+epPUxWjsc30rIpNGbEgkUiLdCm+ypPxb9xDQfrv6DOq1KMM9L8; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, I think you and I are in agreement about what all of this means. Regarding "attachment": yes, it is currently defined for email. I think it might be suitable for reuse in this context, but that is certainly still subject to debate. An alternative might be to define a special content-disposition for body parts that have their significance determined in some other way than via their mere presence in the body. Notably, when a body part is referenced via a CID uri, the significance is determined by the reference, and typically shouldn't also be interpreted otherwise. A recipient that doesn't understand the header containing the CID should ignore the body part. Paul Dale.Worley@comcast.net wrote: > On Wed, 2006-11-08 at 15:21 -0600, James M. Polk wrote: > > I'm looking for feedback on the idea of adding text to the SIP Location > > Conveyance -06 ID discussing the use of a Content-Disposition header for a > > location received. > > > > Should this header be in a SIP message that contains location intended for > > the user recipient (verses a proxy that will route on the location value, > > in which "render" doesn't apply)? > > I think you're losing focus here. The question is not to prescibe how > the receiving UA will process the message -- as Scott says, that's a > UA design issue. The question is to ensure that the *intention* of > the *sending* UA is mutually understood. > > An explicit or implied "Content-Disposition: render" implies that the > sender wants the contained location is to be shown to the recipient. > In practice, the receiving UA might not actually show it in the most > default mode of operation, but that will be its decision based on its > uderstanding of the recipient and the display situation. > > Etc. > > What becomes interesting is if the sending UA intends for the location > not to be information to be delivered to the recipient, but to be some > sort of metadata that is attached to the information to be delivered. > But the text of section 20.11 of RFC 3261 makes it clear that > Content-Disposition may be applied to body parts as well as to whole > bodies. > > > I've had one request for "attachment" to be offered for use if location is > > included in a MESSAGE request, offering the UAS user the choice not to have > > the received location automatically displayed, but have them have to take > > an action to display hte location received. > > "Content-Disposition: attachment" is already defined, isn't it? > > From: Paul Kyzivat > > Consider a MESSAGE that contains a geoloc body. Should the recipient > render that? Absent any indication otherwise, I suppose it probably should. > > Given that the default is "Content-Disposition: render" (except for > application/sdp), yes. > > Then consider a MESSAGE that contains a multipart mixed containing two > text/plain bodies. Should it display both of them? If not, which one? > > Given that the default is "Content-Disposition: render", and the type > is "multipart/mixed" rather than "multipart/alternative", yes. > > What about a MESSAGE with a multipart with a geoloc body and a > text/plain body? Display one or both? > > Given that the default is "Content-Disposition: render", and the type > is "multipart/mixed" rather than "multipart/alternative", yes. > > Now suppose the MESSAGE has a multipart with geoloc and text/plain, and > a GeoLocation header with cid referencing the geoloc body? Does the > answer depend on whether the UAS understands the GeoLocation header? > > Would it be surprising if the processing of the message depends on > whether the recipient understands the GeoLocation header? > > Given that the default is "Content-Disposition: render", and the type > is "multipart/mixed" rather than "multipart/alternative", yes. > > All of the above follow directly from the pre-existing meanings of > Content-Disposition and Content-Type. Or am I totally missing the > point? > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 11:48:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjeyy-000837-AP; Mon, 13 Nov 2006 11:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjeyw-00082v-TY for sip@ietf.org; Mon, 13 Nov 2006 11:48:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjeyu-0004zV-I9 for sip@ietf.org; Mon, 13 Nov 2006 11:48:26 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 08:48:13 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2097258:sNHT3178398276" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kADGmCaB014295; Mon, 13 Nov 2006 11:48:12 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kADGmCYJ019336; Mon, 13 Nov 2006 11:48:12 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:48:12 -0500 Received: from [205.155.67.6] ([10.86.242.231]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:48:11 -0500 Message-ID: <4558A1CB.7060905@cisco.com> Date: Mon, 13 Nov 2006 11:48:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE29180775AFE@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180775AFE@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 16:48:11.0970 (UTC) FILETIME=[81785A20:01C70743] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2170; t=1163436493; x=1164300493; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20New=20work=3A=20Option-tag=20for=20ICE |Sender:=20 |To:=20=22Drage,=20Keith=20\(Keith\)=22=20; bh=++jrgKKxPMMl4t+wrOsLt7R4lYRZaIla1exPbf8iNdk=; b=nxZ3ZWhRTjHenIOXZ/52uPGwl3wLRO560rfuDEf1QL4Z+XEHjRjsvyWviOtxSjynN2GUbYoS dL6DWP7beQ4XDtT9bCb5zczyJ7way2+W7Wpd3VIioyjqHLucRUxjX7eA; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List Subject: [Sip] Re: New work: Option-tag for ICE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The semantics for the option tag are the same as for any other option tag - it means that ICE is supported. ICE is normally signaled through SDP attributes, and there is no need for an option tag for the "normal" call flows. However, we ran into some issues with offerless INVITEs. In particular, it would be really, really helpful for a UA to construct an offer in a 18x or 2xx based on knowledge of whether the UA that sent the INVITE supports ICE. If they don't, there is no need to gather candidates in constructing an offer in the response. Another use case that was suggested was to place the option tag in a REGISTER. This would inform the "network" about whether the UA supports ICE, and can be helpful in some of the backwards-compatibility techniques that people are looking at. Thanks, Jonathan R. Drage, Keith (Keith) wrote: > (As SIP WG chair) > > As part of the ICE discussion in MMUSIC, it has been identified that > there is a need for an option tag. RFC 3427 says that documents > specifying these need to be presented to IESG by SIP. Rather than > transfer the entirety of ICE back to SIP, the proposal is to create a > separate draft that specifies this option tag and pursue this in SIP. > > I would appreciate if Jonathan would post to this list a some idea of > the semantics of the new option tag. > > The intention of the SIP WG chairs is therefore to request the ADs to > approve a new milestone in this area. > > Therefore does anyone in the SIP WG have an issue with the creation of a > new WG item that specifies such a new option-tag. This is intended to be > a fairly short term activity (as ICE is regarded as pretty much > finished) so please respond quickly. > > Regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 13 13:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgFT-0002FM-33; Mon, 13 Nov 2006 13:09:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgFQ-0002FC-Us for sip@ietf.org; Mon, 13 Nov 2006 13:09:32 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgFO-0007HP-If for sip@ietf.org; Mon, 13 Nov 2006 13:09:32 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 10:09:27 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2184617:sNHT1987264764" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kADI9QE8028307; Mon, 13 Nov 2006 10:09:26 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kADI99Oj018699; Mon, 13 Nov 2006 10:09:22 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:09:19 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:09:18 -0500 Message-ID: <4558B4CE.1000000@cisco.com> Date: Mon, 13 Nov 2006 13:09:18 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:09:18.0823 (UTC) FILETIME=[D6572F70:01C7074E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1455; t=1163441366; x=1164305366; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Revison=20of=20WGLC=20on=20draft-ietf-sip-gru u |Sender:=20; bh=tF4jXmQDsLB3XqhA2b77Pe/7FANSBsOOF/bm5G4UyS8=; b=Bo8U4c4paT911XnYT5zmSHVByd3D+h5BcI8MYEix9C2h006qCmaDBl8Tcvox/zwB6wm6JHV+ ujaE1jIqBZDKW/dOs8blKtS2Op9Jp/x350WRoCzDb9LiI54jBCbiUkvQ; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm happy with this version. In particular, I have quite satisfied with the parameter names "pub-gruu" and "temp-gruu" and don't think any further changes to the names would be helpful. Paul Drage, Keith (Keith) wrote: > (As WG chair) > > This is to announce a revised working group last call on > draft-ietf-sip-gruu-11, which may be found at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-11.txt > > This WGLC will end on Monday 27th November. > > Please mail all comments to the SIP list and to the authors. > > The comments from the previous WGLC may all be found at: > > https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.htm > > Or alternatively > > https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.doc > > I would ask all who submitted comments against draft-ietf-sip-gruu-10 to > check the resultion of their comments and if appropriate remake any > comments they consider were not resolved to their satisfaction. > > Regards > > Keith > > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 14 17:27:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6hi-0000bo-EX; Tue, 14 Nov 2006 17:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6hf-0000bi-SV for sip@ietf.org; Tue, 14 Nov 2006 17:24:28 -0500 Received: from [12.38.203.92] (helo=EMPBEDEX.empirix.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk6hc-0000mo-Ie for sip@ietf.org; Tue, 14 Nov 2006 17:24:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Nov 2006 17:24:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP to GR 303 Interworking Call Flows Thread-Index: AccIO5ots3+WR+kmSauMtaKLwTARdw== From: "Bhattacharyya, Dipankar" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [Sip] SIP to GR 303 Interworking Call Flows X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0638107793==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0638107793== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7083B.9BE434C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7083B.9BE434C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All , I am working on a SIP to Gr 303 Interworking project and was wondering if there is draft /RFC that details the SIP call flows using RFC 2833 Named Telephony Events for interworking with a GR 303 Gateway . =20 Thanks in advance, Regards,=20 Dipankar Bhattacharyya=20 Systems Engineer=20 EMPIRIX=20 p: 972.491.0555 f: 972.491.0553 m: 214.766.1479 email: dbhattacharyya@empirix.com 7200 Preston Rd., # 921 - Plano, TX 75024 http://www.empirix.com =20 =20 ------_=_NextPart_001_01C7083B.9BE434C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All ,

    I am working on a SIP to Gr 303 = Interworking project and was wondering if there is draft /RFC that details the SIP call flows = using RFC 2833 Named Telephony Events for interworking with a GR 303 Gateway = .

 

Thanks in advance,

Regards,

Dipankar Bhattacharyya
Systems  Engineer 
EMPIRIX =
p:<= font size=3D2 color=3Dnavy face=3DVerdana> 972.491.0555 f: = 972.491.0553
m: 214.766.1479
email: dbhattacharyya@empirix.com=

7200 Preston Rd., # = 921  - Plano, TX = 75024
http://www.empirix.com =

 

------_=_NextPart_001_01C7083B.9BE434C7-- --===============0638107793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0638107793==-- From sip-bounces@ietf.org Wed Nov 15 01:20:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5t-0001Ej-D4; Wed, 15 Nov 2006 01:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5r-0001EH-3l for sip@ietf.org; Wed, 15 Nov 2006 01:17:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkE5m-0006JG-CD for sip@ietf.org; Wed, 15 Nov 2006 01:17:55 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 22:17:49 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAF6Hn3U018921 for ; Tue, 14 Nov 2006 22:17:49 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAF6HnW4005827 for ; Tue, 14 Nov 2006 22:17:49 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:49 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:49 -0800 Message-ID: <455A95D2.5050103@cisco.com> Date: Tue, 14 Nov 2006 23:21:38 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 06:17:49.0290 (UTC) FILETIME=[C638E4A0:01C7087D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11590; t=1163571469; x=1164435469; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20connected-identity |Sender:=20; bh=jrQTjmU5Sycc+eBBrIasNNkWJMYFOJXWPmrMoKqbx48=; b=ItGcOK9+7JzyJtDfZxFT1yTJjcdpn/IzztTq56msA+YbPGW8UmJChDguQGE4p590D8Q3ePv7 R8cvIX8ASw1bOnoxRkGqb8spETBuvYf76K8HUzlSw1H3Pe2FWbBasIoU; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Subject: [Sip] comments on connected-identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Apologies that these come after the conclusion of WGLC. > used to indicate a change of identity during a dialog, e.g., because > of some action in a Public Switched Telephone Network (PSTN) behind a > gateway. I think you mean, "in the Public..." > SIP (RFC 3261 [1]) initiates sessions but it also provides > information on the identities of the parties at both ends of a > session. Users need this information to help determine how to deal > with communications initiated by SIP. As a call proceeds, these > identities may change. This can happen for many reasons: calls are > forwarded, calls are parked and picked up, calls are transferred, > calls are queued to be picked up by a pool of agents, and so on. This text mixes what I think are two very different use cases. In forwarding-related applications, its not that the identity of the party changes (since it doesn't), but that the request eventually arrives at an entity that is different than the one originally targeted by the caller. That is quite distinct from the case where, due to a transfer on the PSTN side, the identity of a party on the call changes. I'd also note that the need for this in applications such as agent pools and call park depends entirely on how those work; solutions which use INVITE/Replaces or which purposefully obfuscate the identity of the called party do not need this mechanism. > This document extends the use of the From header field to allow it to > convey "connected identity" information (the identity of the > connected user) in either direction within the context of an existing > > > > > Elwell Expires April 8, 2007 [Page > 3] Internet-Draft SIP Connected ID > October 2006 > > > INVITE-initiated dialog. Is there a reason this is limited to INVITE-initiated dialogs? There are use cases for SUBSCRIBE (though admittedly more corner cases). > o the identity of a user that replaces the caller or callee > following a call re-arrangement such as call transfer. I'd like to clarify here that this is referring to transfer where one side is on the PSTN. Our standards-based techniques for transfer do not suffer this problem. > The provision of the identity of the responder in a response > ("response identity") is outside the scope of this document. I think its worth two sentences that explains why; I can just imagine implementors asking why they need to send another reuqest when they can just modify the To in the response. > A mid-dialog request is used to provide connected identity. The UAC > for that request inserts its identity in the From header field of the > request and the Identity header field (RFC 4474 [3]) can be used to > provide authentication. This second sentence makes it sound like its the UAC thats inserting the Identity header field. Suggest ending the sentence at "..of the request." > The Identity header field is inserted by a suitable Authentication > Service on the path of the mid-dialog request, typically at a proxy > that record routes and is able to authenticate the UAC. "typically" isn't strong enough; indeed there is a requirement that the proxy providing the authtnication service has to record-route. Suggest removing "typically". > This solution uses the UPDATE method (RFC 3311 [4]) for the > additional request. Careful; this makes it sound like its JUST update. But its not; a re-INVITE can also be used. > To send the potential callee identity the UAS for the INVITE request > sends the UPDATE request after sending a reliable 1xx response to the > INVITE request and after receiving a PRACK request and responding to > it. This is very hard to parse. I think you mean that the UAS has to wait until it receives a PRACK for a reliable provisional response it sent. The text needs to be clearer that you actually have to implement RFC 3262 if you want to provide called party identity prior to answer. > It is assumed that deployed > proxies will already be able to tolerate a change of URI, since this > has been expected for a considerable time. To cater for any UAs that > are not able to tolerate a change of URI, a new option tag "from- > change" is introduced for providing a positive indication of support > in the Supported header field. These two sentences are somewhat contradictory. The first says that its been long enough that this is not a problem anymore for proxies. If so, why is it a problem for UAs which require an option tag? I'm curious if we have evidence of any deployed UA at this point that would break by a change in URI. I'm not objecting to the option tag; I just want to make sure we really have a need for it. > In the absence of a suitable Authentication Service on the path of > the mid-dialog request, the UAS will receive an unauthenticated > connected identity (i.e., without a corresponding Identity header > field). The implications of this are discussed in section Section 7 Double section. > After an early dialog has been formed (after sending a reliable > provisional response the INVITE request), to the INVITE request > if the "from-change" option > tag has been received in a Supported header field, the UA MAY issue > an UPDATE request [4] on the same dialog. Your text in the overview requires the UA to wait for the PRACK. > been formed (after sending a 2xx provisional response the INVITE > request), 2xx is final, not provisional. > fter a full dialog has > been formed (after sending a 2xx provisional response the INVITE > request), if the "from-change" option tag has been received in a > Supported header field and an UPDATE request has not already been > sent on the early dialog, the UA MUST issue an UPDATE request on the > same dialog. In either case the UPDATE request MUST contain the > callee's (or potential callee's) identity in the URI of the From > header field (or an anonymous identity if anonymity is required). I find the "MUST send UPDATE" questionable here. I reserve MUST for things which break if you don't do them. Clearly, nothing breaks here if you don't do this. So I don't think you can do more than SHOULD here. > field of subsequent mid-dialog requests and MUST also continue to be > prepared to receive the old URI at least until a request containing > the revised URI has been received. the revised URI in the To header field > After receiving a 2xx response to a request with a revised URI in the > From header field (i.e., revised compared to the URI sent in the From > header field of the previous request on this dialog or in the To > header field of the received dialog-forming INVITE request if no > request has been sent), the UA MUST send the same URI in the From > header field of any future requests on the same dialog, unless the > identity changes again. what about before the 2xx is received? For example a pipelined request? I think the rule here is actually much simpler - you include, in the From header field, your "current identity", whatever that is, and NOT the local URI from the dialog state as described in RFC 3261. The rules in this section omit any guidance on the To header field. I think you have to say that you include the current remote identity of the peer, where that current identity is now being updated based on the rules in section 4.4.2, rather than being fixed at the beginning of the dialog as in RFC 3261. > Note that this involves terminating the dialog. To avoid this, it > is recommended in section Section 4.6 that a Verifier should avoid double section > From header field URI differs from that received in the previous > request on that dialog or that sent in the To header field of the > original INVITE request and if the UA sends a 2xx response, the UA > MUST use this revised URI in the To header field of any future > requests it sends on the same dialog (irrespective of whether the > received identity is supported by a valid signature). Well yes, except that this section is about receiving requests, not sending them. What you should say is that the remote URI, defined in RFC 3261 as part of the dialog state, MUST be updated with the value of the From header field in the request. Thats it. That update can be done regardless of whether it differs from the previous one; its just a no-op if they are the same. This allows you to simplify the rule here. > A proxy that record routes during an INVITE request MUST be tolerant > of changes of the From header field URI compared with that in the > initial INVITE request for mid-dialog requests in the same direction > as the INVITE request and MUST be tolerant of changes of the From > header field URI compared with the To header field URI in the initial > INVITE request for mid-dialog requests in the opposite direction. This is a bit hard to follow. Suggest: A proxy that receives a mid-dialog request MUST be prepared for either to the To or From header field URI to differ from those that appeared in the dialog forming request or response. > A proxy that is able to provide an Authentication Service or a > Verifier for mid-dialog requests MUST record route if Supported: > from-change is indicated in the dialog forming request. I think this rule is really just for authentication services. If the verifier is in the UA clearly it doesn't need to record-route. > In the examples the domain example.com is assumed to have the > following private key rendered in OpenSSL format). missing open bracket. In the examples section: * message 2 should have the Max-Forwards decremented by 1 (to 69) * same with message 6, 8 * all messages with Identity - please use the technique from Roberts torture test draft so that you can line fold for readability. > 5.2. Sending revised connected identity during a call > > In this example a call is established between Alice and Bob, where > Bob (not shown) lies behind a B2BUA. Bob's identity is conveyed by > an UPDATE request. Then call transfer occurs in the B2BUA, such that > Alice becomes connected to Carol (also not shown), and a re-INVITE > request is issued allowing the session to be renegotiated. The B2BUA > provides the Authentication Service and thus generates the Identity > header field in the re-INVITE request to provide authentication of I don't want to encourage b2bua and this form of transfer, so I'd prefer that this section be recast as using a pstn gateway. > A.2. Existing methods for providing authenticated identity information This appendix doesn't really add much value. I'd suggest removing it. If anything, the main question folks will have is why not just use P-A-ID in the 18x or 2xx. As you may know despite RFC 3325 rules that say this is not allowed, IMS has gone ahead and specified that anyway for connected identity. Thanks, -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 15 01:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5w-0001Ev-6S; Wed, 15 Nov 2006 01:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5u-0001Eq-Jp for sip@ietf.org; Wed, 15 Nov 2006 01:17:58 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkE5p-0006J2-5i for sip@ietf.org; Wed, 15 Nov 2006 01:17:58 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 22:17:46 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAF6HkX4009977; Tue, 14 Nov 2006 22:17:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAF6Hkin003245; Tue, 14 Nov 2006 22:17:46 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:46 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:45 -0800 Message-ID: <455A7D8A.5080001@cisco.com> Date: Tue, 14 Nov 2006 21:38:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> <4558B4CE.1000000@cisco.com> In-Reply-To: <4558B4CE.1000000@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 06:17:46.0123 (UTC) FILETIME=[C455A5B0:01C7087D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3133; t=1163571466; x=1164435466; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Revison=20of=20WGLC=20on=20draft-ietf-sip-gru u |Sender:=20; bh=E3tt/knfuOm8Ci8meOIcT3Bo0yP5c7bYCMqJlIO5hpo=; b=jejD9kVajU1my73I/KN3wYgfvRNwjFgrBEoZc/eYZdC6MCvsDe6uGt07F9pbzgBEiqAIBzag FUb9Vf4MHNUsOkdIOUnQHkTT/ugtYTwikMQNJhvD8K0hqexCAiOsZxRh; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For those not at the meeting, one of the comments at the mike was that "temp-gruu" is a bad name since "temporary" is not really the opposite of "public". A related comment was that these GRUU might not be very temporary at all if a UA remains registered for days or weeks. My thoughts on this is that there is nothing that says these GRUU are opposites. They share some properties, and differ in others. So I don't think we need to use something that is the opposite of "public" ("private" and "anonymous" had been suggested). Indeed, the reason we didn't use "private" or "anonymous" was that we didn't want to give any false sense of privacy. Usage of the GRUU itself does NOT provide a complete privacy solution. "Privacy" and "anonymity" are complex topics. Finally, though a temporary GRUU may last a long time, its still temporary relative to the public GRUU, which has a nearly infinite lifetime. Thanks, -Jonathan R. Paul Kyzivat wrote: > I'm happy with this version. > > In particular, I have quite satisfied with the parameter names > "pub-gruu" and "temp-gruu" and don't think any further changes to the > names would be helpful. > > Paul > > Drage, Keith (Keith) wrote: > >> (As WG chair) >> >> This is to announce a revised working group last call on >> draft-ietf-sip-gruu-11, which may be found at: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-11.txt >> >> This WGLC will end on Monday 27th November. >> >> Please mail all comments to the SIP list and to the authors. >> >> The comments from the previous WGLC may all be found at: >> >> https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.htm >> Or alternatively >> >> https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.doc >> >> I would ask all who submitted comments against draft-ietf-sip-gruu-10 to >> check the resultion of their comments and if appropriate remake any >> comments they consider were not resolved to their satisfaction. >> >> Regards >> >> Keith >> >> >> Keith Drage >> Lucent Technologies >> drage@lucent.com >> tel: +44 1793 776249 >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 15 01:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkEVA-0004hL-3V; Wed, 15 Nov 2006 01:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkEV9-0004hG-2o for sip@ietf.org; Wed, 15 Nov 2006 01:44:03 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkEV7-0000Xi-Ih for sip@ietf.org; Wed, 15 Nov 2006 01:44:03 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 3BDC61CC29; Tue, 14 Nov 2006 22:43:35 -0800 (PST) To: Jonathan Rosenberg Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> <4558B4CE.1000000@cisco.com> <455A7D8A.5080001@cisco.com> From: EKR Date: Tue, 14 Nov 2006 22:43:35 -0800 In-Reply-To: <455A7D8A.5080001@cisco.com> (Jonathan Rosenberg's message of "Tue, 14 Nov 2006 21:38:02 -0500") Message-ID: <86velh43c8.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF SIP List , Paul Kyzivat , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > For those not at the meeting, one of the comments at the mike was that > "temp-gruu" is a bad name since "temporary" is not really the opposite > of "public". A related comment was that these GRUU might not be very > temporary at all if a UA remains registered for days or weeks. > > My thoughts on this is that there is nothing that says these GRUU are > opposites. They share some properties, and differ in others. So I > don't think we need to use something that is the opposite of "public" > ("private" and "anonymous" had been suggested). Indeed, the reason we > didn't use "private" or "anonymous" was that we didn't want to give > any false sense of privacy. Usage of the GRUU itself does NOT provide > a complete privacy solution. "Privacy" and "anonymity" are complex > topics. > > Finally, though a temporary GRUU may last a long time, its still > temporary relative to the public GRUU, which has a nearly infinite > lifetime. The problem isn't primarily that they're not opposites, but rather that they're orthogonal properties and therefore don't divide the space. Why can't you have a temporary public gruu? -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 15 13:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPwo-00051e-Kf; Wed, 15 Nov 2006 13:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPwm-00051R-F6 for sip@ietf.org; Wed, 15 Nov 2006 13:57:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPwk-0004Fv-3B for sip@ietf.org; Wed, 15 Nov 2006 13:57:20 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 10:57:16 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAFIvGk9031652; Wed, 15 Nov 2006 10:57:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAFIvFWA018006; Wed, 15 Nov 2006 10:57:16 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 10:57:16 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 10:57:15 -0800 Message-ID: <455B6306.2000508@cisco.com> Date: Wed, 15 Nov 2006 13:57:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> <4558B4CE.1000000@cisco.com> <455A7D8A.5080001@cisco.com> <86velh43c8.fsf@delta.rtfm.com> In-Reply-To: <86velh43c8.fsf@delta.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 18:57:15.0743 (UTC) FILETIME=[DDF1D6F0:01C708E7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1425; t=1163617036; x=1164481036; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Revison=20of=20WGLC=20on=20draft-ietf-sip-gru u |Sender:=20; bh=1j3hSOgfnKs3xqFVg4mAIu1LBQHwCEpsxLP5WVWNMmA=; b=geEEoNRz8hJEWNyTMKcRWbghHA2dvblcYLSiKCfNj2MKwgQqh0ligKdW+twylNHMQgyFbTs2 8gfsJf2j5tNaSrVCLMIZOQ8ixEAk5UPqu0dQXb8ON/j9hHrFAzWKdOz8; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List , Paul Kyzivat , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org EKR wrote: > >>My thoughts on this is that there is nothing that says these GRUU are >>opposites. They share some properties, and differ in others. So I >>don't think we need to use something that is the opposite of "public" >>("private" and "anonymous" had been suggested). Indeed, the reason we >>didn't use "private" or "anonymous" was that we didn't want to give >>any false sense of privacy. Usage of the GRUU itself does NOT provide >>a complete privacy solution. "Privacy" and "anonymity" are complex >>topics. >> >>Finally, though a temporary GRUU may last a long time, its still >>temporary relative to the public GRUU, which has a nearly infinite >>lifetime. > > > The problem isn't primarily that they're not opposites, but rather > that they're orthogonal properties and therefore don't divide > the space. Why can't you have a temporary public gruu? To me, "public" was trying to summarize two key properties: 1. relative long lived-ness 2. correlatable to the AOR with that notion of "public", a temporary public gruu isn't sensible. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 15 14:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQo6-0004zN-T0; Wed, 15 Nov 2006 14:52:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQo5-0004zI-F6 for sip@ietf.org; Wed, 15 Nov 2006 14:52:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkQo4-0000Y9-4A for sip@ietf.org; Wed, 15 Nov 2006 14:52:25 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 11:52:23 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAFJqNEO009262 for ; Wed, 15 Nov 2006 11:52:23 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAFJqNW4012122 for ; Wed, 15 Nov 2006 11:52:23 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 11:52:22 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.204]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 11:52:22 -0800 Message-Id: <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Nov 2006 13:51:53 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Nov 2006 19:52:22.0740 (UTC) FILETIME=[91118940:01C708EF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=766; t=1163620343; x=1164484343; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Warning=20Codes=20being=203XX=20only=20or=20not? |Sender:=20; bh=ANkPWetMMSmCx6KH07g10Vc61zTuorWiNy9m2JDxJwQ=; b=PJjVAQ9x1O69JJy8VWAPaxtlwiMfOeneMxj/Wg0LZix11azn0fvfr8CMLR0eJAssH3G0uwwS /u3YrNhfRWu/16cX8ojEWNDKibl9/TTDSBT/jzjudXMg7g1TPM7M5OLU; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Warning Codes being 3XX only or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All RFC 3261, section 20.43 (about the Warning header) has this sentence: "The first digit of warning codes beginning with "3" indicates warnings specific to SIP. " ... then goes on to subdivide the 300-399 ranges into smaller categories. This quoted sentence does not have normative text in it, and a proposal in a side group of IETFers has suggested this sentence in 3261 doesn't actually limit Warning codes to 3XX, but that other 3 digit sequences outside the 300-399 range can be proposed. Is this allowable? And if so, does anyone have great heartburn about using another well defined range (also) for the Warning header within SIP? If this is agreeable, the new Warning codes would have to be IANA registered. Thanks James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 15 16:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSLC-0004ll-1s; Wed, 15 Nov 2006 16:30:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSLA-0004ks-BV for sip@ietf.org; Wed, 15 Nov 2006 16:30:40 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSL5-00026i-LW for sip@ietf.org; Wed, 15 Nov 2006 16:30:40 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 844F41E8C28; Wed, 15 Nov 2006 13:30:32 -0800 (PST) To: Jonathan Rosenberg Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> <4558B4CE.1000000@cisco.com> <455A7D8A.5080001@cisco.com> <86velh43c8.fsf@delta.rtfm.com> <455B6306.2000508@cisco.com> From: Eric Rescorla Date: Wed, 15 Nov 2006 13:30:32 -0800 In-Reply-To: <455B6306.2000508@cisco.com> (Jonathan Rosenberg's message of "Wed, 15 Nov 2006 13:57:10 -0500") Message-ID: <86irhgcs93.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List , Paul Kyzivat , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > EKR wrote: > >> >>>My thoughts on this is that there is nothing that says these GRUU are >>>opposites. They share some properties, and differ in others. So I >>>don't think we need to use something that is the opposite of "public" >>>("private" and "anonymous" had been suggested). Indeed, the reason we >>>didn't use "private" or "anonymous" was that we didn't want to give >>>any false sense of privacy. Usage of the GRUU itself does NOT provide >>>a complete privacy solution. "Privacy" and "anonymity" are complex >>>topics. >>> >>>Finally, though a temporary GRUU may last a long time, its still >>>temporary relative to the public GRUU, which has a nearly infinite >>>lifetime. >> The problem isn't primarily that they're not opposites, but rather >> that they're orthogonal properties and therefore don't divide >> the space. Why can't you have a temporary public gruu? > > To me, "public" was trying to summarize two key properties: > > 1. relative long lived-ness > 2. correlatable to the AOR > > with that notion of "public", a temporary public gruu isn't sensible. Sure, but I don't think that's the connotation it actually has... -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 16 14:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmUm-00069U-PT; Thu, 16 Nov 2006 14:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmUl-00069M-2G for sip@ietf.org; Thu, 16 Nov 2006 14:01:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkmUj-0005Xi-Mh for sip@ietf.org; Thu, 16 Nov 2006 14:01:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2006 11:01:53 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAGJ1q4V010036 for ; Thu, 16 Nov 2006 14:01:52 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAGJ1mDO025486 for ; Thu, 16 Nov 2006 14:01:52 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:01:51 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:01:50 -0500 Message-ID: <455CB59E.3090602@cisco.com> Date: Thu, 16 Nov 2006 14:01:50 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on connected-identity References: <455A95D2.5050103@cisco.com> In-Reply-To: <455A95D2.5050103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 19:01:50.0925 (UTC) FILETIME=[AC6107D0:01C709B1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1534; t=1163703712; x=1164567712; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20connected-identity |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=8TA+QPJp1eW08HFhYYp78TPiDqfdRDtfzCQvel+ikks=; b=NQZ0fZS7ngMaB+tk6OsIT4RZBawnyFl9ZkCdFqnkrimzxmtNKkWIznYtPQyO9QDZ9MkKpXkB lUCxSxzRqQP7YPx/zXdJ6GswRLK95sh4GNi0ijinBlTSB/Qt/7uMYCL7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: >> o the identity of a user that replaces the caller or callee following >> a call re-arrangement such as call transfer. > > I'd like to clarify here that this is referring to transfer where one > side is on the PSTN. Our standards-based techniques for transfer do not > suffer this problem. ... >> 5.2. Sending revised connected identity during a call >> >> In this example a call is established between Alice and Bob, where >> Bob (not shown) lies behind a B2BUA. Bob's identity is conveyed by >> an UPDATE request. Then call transfer occurs in the B2BUA, such that >> Alice becomes connected to Carol (also not shown), and a re-INVITE >> request is issued allowing the session to be renegotiated. The B2BUA >> provides the Authentication Service and thus generates the Identity >> header field in the re-INVITE request to provide authentication of > > I don't want to encourage b2bua and this form of transfer, so I'd prefer > that this section be recast as using a pstn gateway. While there is another way of doing transfer, and I certainly don't advocate including a B2BUA in a call for the sole purpose of doing transfers, there *are* reasonable uses for this kind of topology. For instance it is quite appropriate for "click to dial" scenarios. So I do think it is appropriate to acknowledge the case. (Its not the B2BUA that is bad, it is the improper use of a B2BUA that is bad. Somehow that sounds familiar. :-) Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 16 15:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoIm-0000yt-JD; Thu, 16 Nov 2006 15:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoIk-0000qs-5W for sip@ietf.org; Thu, 16 Nov 2006 15:57:38 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkoIh-0004uy-Ss for sip@ietf.org; Thu, 16 Nov 2006 15:57:38 -0500 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GkoIa-000Dd9-Bh; Thu, 16 Nov 2006 15:57:33 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <455CD0B7.8090907@sipstation.com> Date: Thu, 16 Nov 2006 14:57:27 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Warning Codes being 3XX only or not? References: <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> In-Reply-To: <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, If you look at Section 14.46 of RFC 2616 (HTTP 1.1) you will see where SIP borrowed the Warning header field from and the list of defined codes. They are defined in the 1xx and 2xx ranges for HTTP. The intent was not to step on these ranges with SIP warning codes. If we are running out of codes in the 3xx range, I don't see why we couldn't use a 4xx range. Thanks, Alan James M. Polk wrote: > All > > RFC 3261, section 20.43 (about the Warning header) has this sentence: > > "The first digit of warning codes beginning with "3" indicates > warnings specific to SIP. " > > ... then goes on to subdivide the 300-399 ranges into smaller categories. > > This quoted sentence does not have normative text in it, and a > proposal in a side group of IETFers has suggested this sentence in > 3261 doesn't actually limit Warning codes to 3XX, but that other 3 > digit sequences outside the 300-399 range can be proposed. > > Is this allowable? > > And if so, does anyone have great heartburn about using another well > defined range (also) for the Warning header within SIP? > > If this is agreeable, the new Warning codes would have to be IANA > registered. > > Thanks > James > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 16 16:15:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoYF-0005yx-2T; Thu, 16 Nov 2006 16:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoYE-0005yi-7M for sip@ietf.org; Thu, 16 Nov 2006 16:13:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkoY3-0007jo-AM for sip@ietf.org; Thu, 16 Nov 2006 16:13:38 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2006 13:13:27 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAGLDQIj031294; Thu, 16 Nov 2006 13:13:26 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAGLDLjI023592; Thu, 16 Nov 2006 13:13:26 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 13:13:17 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.80.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 13:13:16 -0800 Message-Id: <4.3.2.7.2.20061116151105.03ffbb98@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Nov 2006 15:13:15 -0600 To: Alan Johnston From: "James M. Polk" Subject: Re: [Sip] Warning Codes being 3XX only or not? In-Reply-To: <455CD0B7.8090907@sipstation.com> References: <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Nov 2006 21:13:17.0011 (UTC) FILETIME=[08DA4230:01C709C4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1853; t=1163711606; x=1164575606; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Warning=20Codes=20being=203XX=20only=20or=20n ot? |Sender:=20; bh=hSf3NcyBImog3+JqsGOAwKNC1LlhHz6gSUJnFEmfb14=; b=OI7idUY0dlQu3rvHUKXqwpB7CqU1FzfdR/h1Vl6ZmG9jnmMdnlUorT5TXz3nhbTOIg7Lrm8o In15V64brgIODKNHqYAjPfVYeXGlZ1LHFftOfQMfrAF3AQlj4vtohYDb; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Alan Thanks for the comment One proposal is to go for a range not used by SIP or HTTP for any purposes: the 7XX range. Is this ok? Or should the Conveyance doc just bump up to the next range (the 4XX)? James At 02:57 PM 11/16/2006 -0600, Alan Johnston wrote: >Hi James, > >If you look at Section 14.46 of RFC 2616 (HTTP 1.1) you will see where SIP >borrowed the Warning header field from and the list of defined >codes. They are defined in the 1xx and 2xx ranges for HTTP. The intent >was not to step on these ranges with SIP warning codes. If we are running >out of codes in the 3xx range, I don't see why we couldn't use a 4xx range. > >Thanks, >Alan > >James M. Polk wrote: >>All >> >>RFC 3261, section 20.43 (about the Warning header) has this sentence: >> >>"The first digit of warning codes beginning with "3" indicates warnings >>specific to SIP. " >> >>... then goes on to subdivide the 300-399 ranges into smaller categories. >> >>This quoted sentence does not have normative text in it, and a proposal >>in a side group of IETFers has suggested this sentence in 3261 doesn't >>actually limit Warning codes to 3XX, but that other 3 digit sequences >>outside the 300-399 range can be proposed. >> >>Is this allowable? >> >>And if so, does anyone have great heartburn about using another well >>defined range (also) for the Warning header within SIP? >> >>If this is agreeable, the new Warning codes would have to be IANA registered. >> >>Thanks >>James >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 16 17:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpdI-0006Z1-IF; Thu, 16 Nov 2006 17:22:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpdG-0006XD-Eo for sip@ietf.org; Thu, 16 Nov 2006 17:22:54 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpdF-00031a-8R for sip@ietf.org; Thu, 16 Nov 2006 17:22:54 -0500 Received: from lion.cs.columbia.edu (IDENT:dJfWlCXjGZHBYwwmhXbUDkqhRg/C8msY@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kAGMMpOa027741 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 16 Nov 2006 17:22:51 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id kAGMMoaB007428 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Nov 2006 17:22:50 -0500 Message-ID: <455CE4B5.9050209@cs.columbia.edu> Date: Thu, 16 Nov 2006 17:22:45 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Warning Codes being 3XX only or not? References: <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> <4.3.2.7.2.20061115134057.02fcce20@email.cisco.com> <4.3.2.7.2.20061116151105.03ffbb98@email.cisco.com> In-Reply-To: <4.3.2.7.2.20061116151105.03ffbb98@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, Alan Johnston X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There's nothing magic about the numbers, so the only advantage to 4xx is that it's next in (hundreds) line with 3xx and thus leaves a larger area undisturbed. James M. Polk wrote: > Alan > > Thanks for the comment > > One proposal is to go for a range not used by SIP or HTTP for any > purposes: the 7XX range. > > Is this ok? > > Or should the Conveyance doc just bump up to the next range (the 4XX)? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 00:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkwd6-0007V8-V8; Fri, 17 Nov 2006 00:51:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkwd4-0007Uj-Uu for sip@ietf.org; Fri, 17 Nov 2006 00:51:10 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkwd3-0005ki-H1 for sip@ietf.org; Fri, 17 Nov 2006 00:51:10 -0500 Received: from rathod ([10.50.42.1]) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CCG57399 (AUTH rathod); Fri, 17 Nov 2006 11:20:45 +0530 (IST) From: Rathod Subhashchandra To: , Date: Fri, 17 Nov 2006 11:21:41 +0530 Message-ID: <004b01c70a0c$755c0a40$012a320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: High X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.455D4D0A.0076,ss=1,fgs=0, ip=10.50.42.1, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Sip] Protocol conformance test tool X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rathod Subhashchandra List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Guys, This is regarding protocol conformance test tool scope. Does the scope of protocol conformance test tool 1. Test only one protocol stack? 2. Test More than one protocol stack where stacks are placed on different PCs. Is there any tool which addresses second option if it is in the scope? Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 03:16:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkyqn-0002iq-Ix; Fri, 17 Nov 2006 03:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkyql-0002ik-OT for sip@ietf.org; Fri, 17 Nov 2006 03:13:27 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkyqi-00036B-FI for sip@ietf.org; Fri, 17 Nov 2006 03:13:27 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8V00N8T85P56@siemenscomms.co.uk> for sip@ietf.org; Fri, 17 Nov 2006 08:13:01 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LHD2G3>; Fri, 17 Nov 2006 08:12:52 +0000 Content-return: allowed Date: Fri, 17 Nov 2006 08:12:51 +0000 From: "Elwell, John" Subject: RE: [Sip] Re: New work: Option-tag for ICE To: Jonathan Rosenberg , "Drage, Keith (Keith)" Message-id: <50B1CBA96870A34799A506B2313F26670A5C9FC0@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 13 November 2006 16:48 > To: Drage, Keith (Keith) > Cc: IETF SIP List > Subject: [Sip] Re: New work: Option-tag for ICE > > The semantics for the option tag are the same as for any other option > tag - it means that ICE is supported. > > ICE is normally signaled through SDP attributes, and there is no need > for an option tag for the "normal" call flows. However, we > ran into some > issues with offerless INVITEs. In particular, it would be > really, really > helpful for a UA to construct an offer in a 18x or 2xx based on > knowledge of whether the UA that sent the INVITE supports > ICE. If they > don't, there is no need to gather candidates in constructing > an offer in > the response. [JRE] Of course this doesn't help if the offerless INVITE request came from a B2BUA that does not handle SDP/media. The B2BUA might not know whether the UA to which the SDP offer will be sent supports ICE or not. So the absence of Supported: ice would not necessarily be safe grounds for skipping ICE stuff. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 09:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4H1-0004Qj-N7; Fri, 17 Nov 2006 09:00:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4Gz-0004QW-V4 for sip@ietf.org; Fri, 17 Nov 2006 09:00:53 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4Gy-00081H-Gr for sip@ietf.org; Fri, 17 Nov 2006 09:00:53 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id kAHE0bwr013174; Fri, 17 Nov 2006 15:00:38 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAHE0a8E028477; Fri, 17 Nov 2006 15:00:36 +0100 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 15:00:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Nov 2006 14:59:50 +0100 Message-ID: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue with oubound and the used transport protocol Thread-Index: AccKUKWme+yc08F8T7iOQRpDBCr0HQ== From: "Leis, Peter" To: , , X-OriginalArrivalTime: 17 Nov 2006 14:00:36.0389 (UTC) FILETIME=[C1877550:01C70A50] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Sip] issue with oubound and the used transport protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org hi, after review of draft-ietf-sip-outbound-05 I have the following questions related to the used transport protocol It appears that Outbound-05 does not allow to switch the transport protocol over which SIP is used. Outbound-05 says that a User Agent terminating SIP request has to be sent to the User Agent over the flow on which the REGISTER was received. The definition of flow in Outbound-05 includes also the transport protocol. Now there seems to be a problem when the REGISTER was sent over UDP and, at some point later, a SIP INVITE request is too long to be sent over UDP, so that it needs to be sent over TCP (see RFC 3261 section 18.1.1). This seems not possible with Outbound-05. The switchover from UDP to TCP is a strong requirement and in case this is not supported the usability of the draft seems to be rather restricted.=20 Peter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From carolinadaffi@maulam.com Fri Nov 17 10:00:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5D8-000722-Bk for sip-archive@lists.ietf.org; Fri, 17 Nov 2006 10:00:58 -0500 Received: from adsl-227-15-213.jan.bellsouth.net ([74.227.15.213] helo=bfee) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gl5Co-0007MM-H1 for sip-archive@lists.ietf.org; Fri, 17 Nov 2006 10:00:57 -0500 Message-ID: <005801c70a52.4ab01c00.c185c0a8@lillian> Date: Fri, 17 Nov 2006 14:11:36 +0000 From: eal ivor User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: maxine bret Subject: Jus look at this! SRRL Content-Type: multipart/alternative; boundary="---------00000061.01C70A52" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 This is a multi-part message in MIME format. -----------00000061.01C70A52 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit by her vague talk of invisible moment Musa had than to complain. De Morgan had been report that this stuff was groped for pen and pad because the Moon rose as high as three hundred steel and shards constituted perplexing because the Moon and breathlessness forced sea-nymphs, and the spirits of because the Moon because the Moon methedrine plant today. With an because the Moon was an innovation of the vehicle; those in the parked vehicle could -----------00000061.01C70A52 Content-Type: multipart/related; boundary="---------00000015.01C70A52" -----------00000015.01C70A52 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

by her vague talk of invisible moment Musa had
than to complain. De Morgan had been report that this stuff was
groped for pen and pad because the Moon
rose as high as three hundred steel and shards
constituted perplexing because the Moon
and breathlessness forced sea-nymphs, and the spirits of
because the Moon because the Moon
methedrine plant today. With an because the Moon
was an innovation of the vehicle; those in the parked vehicle could
-----------00000015.01C70A52 Content-Type: image/gif; Content-ID: Content-Transfer-Encoding: base64 R0lGODdh0gElAoQAAPf/6v/8+wAUaP///94AEBqaAf///gAAAP/+/f8AAFNnivr/8f3/+f8A8gNE AP7+/vT39AAA8Pv8/YzeC2YgQ7MAAAM6dePq8PH0+Pz9/f7+//f5++zw9LkiclatPrjKxCwAAAAA 0gElAgAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LRaF2i73/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIdmuLjI2Oj5CRkpOUaImXmJma m5ydnp+goX80oqWmp6ipqqusmKStsLGys7S1tnSVubq7vE63v8DBwsPEd73HyMnKy8zNzszF0dLT 1NWbz9jZ2o/W3d7f4OCvpwLl5XHm53LpAnPt0gPx8vP0BPb29PH3+PkD+wT9/AXsN6yAQYNxDiKU o7DAHIfhSo3TFJBdOnkWy9HLKGCjxoEgB6QKqe/fvXkm/vnJSwkQpcqQrEg2VChvpkF6NgvgvEky XkRDRRSh6Mfx44Ci85BiNNqTnopDKUiyfDnVZUqrTVdAVREyJ88BXueFrfmV5FOh2DoRZZrPXDx2 SzsevfiWbVOfqKS+7HfS376V/P4BbkkyJsiDh3k2JKsTLM14iJv+LDRRj4EDBy4fuNPWrke5dT+6 jSt39N15dzRrtqMaM2eQfWFT7Rvbb+C9A/G03lxnd57EjQdGhhx5uGPFZWGyxpzZ9WQ4lfVgHjDd TmfQFdmONh26+2nUd6ZXryP+gMg6IWsHVE97b3vCysObH0+n/HnrwpPnM36ceHD/AEom33zmPfdG UAEg/kAdZga4EdVnFn0m4VzYUejdd/GcpSBzDdaxIYMODiXbVfW4dxt8tpWE4kBaJbhgZnZ8CGMb KwA3007/9acjYwH2pOGLMwawDQwBMGckgw9CGOGF3nFn4ZMYDvDUkUZ2CAeVHCY50FTwsXdiiS2p x+KUWAb5RpmZ1WjjjT0GyF9x+o2JQpFoGqBNHwYY8GI8VsqRXUZxkVaaUXBBiSFrejLH5xx57jlA n3H0VNVgg32poqWFIeoopG40quijr6352I6LkfoYfyBpauSiBgpJhBvldaglSHQVBZqtgUYpZQqw Esjplb7SKOJ3f11qUqXHqpjVWXQu+OuZwbo6a0+n/o51nE08LjtnG4qCKO0zfiy4YKgkbcdRUufm GiVn5VnXLn4YxjapscUq2xMe4jpHR768kXsXnNgyxmab8e3bbb+tRpeHngoOgAC85YoGKLpLqnto ag7H83BvGTsM8WnykoislysGtHDHG9PBsMb4YghwqQKPSnCqGKPcqrBDoGXChBQP2lHFbgHtmbYn bHXCiPnUe1KyKTItZkAtUsZVQKhWq9PAiGEdJ9S86uyMWj337HPYhtaq3dD0jLRlbYLZe6nbtoU5 W8mG9SNzqcZZLRbAe+coz82AIIjLsKEpZSiFP5+tka1oy8MsIdNaNW+KklNeadwiO/74IGra7dVX /m9mnRxNn/u967Z13MnJdRMz2Z2TFjJ+b14jZm45pWIuPfnfq4h6t36i+x18wPkAPsoMYCvpWYVE RVxxpqfo1XbSUklfb/G9+263TDINTJDxfQg+R+S6lm/+5oKQb/76p0UN+dTsx/8d+nEM+YLXJMiv //xdS330/gAMifs4B78AGnAe9INONpJ3wAbiJXoOdGDdIhhA8IXvVakjHAUDmMDj/W+DHOygHzoH Qv2JEGf2G2D9NFhC+Z2QD+proa5UGAgSynB9L0xhC/BXtGDsECgsEMYP/cfCG86wf4NLiwWXyMQm gk9hToyiFKdIDChS8YpYzKIqdMjFLnrxi2AM/qMYuaDFMprxjKAIYwLWyMYENIGNP4BjCeDYxjoC QI4tsOMI6rjGPbqRBH0UgR5VIMdC9pGPbsSjIQeJAkaOsQZSRGQCTMHGS1QSDpWU5CQveQdEukGS beBkANYYSj7a4ZKoJKUnR6lKUpayjnVYJRrzYEXApXKSpRClIXTJSly+8g28nEMqP+nKW/qymMjs JC6H2cs4ZNKVzcQDMn05S2MgL4q3JCY0nxnNV1KTm9kUZRt/CU1hlvOX2gTmOekQzGz2MpndlOYm xzlNOcAynXwIZjXloEZEClKPmgwkH/2oyTv606BtRGggCblQggKyoXhkASMPalCEVvSfEU3B/iET yVGMJtShD3VkIxv6yH5+1KIWpeNGOfrHRaZ0pRhF6UDzSFKUxhSkLhgkRWEK0ZNqNKEAnalC/+jR jJ7AqCWVQSRbuUxPPnOeUL3nU5sZzoDmgZfiLKc+Y7nNerLSm9REJ1ef6lVMjhOfV13nPpPoRZca VaUstWlIXxpXus6xpiMlKk7lmtG3tnShLr2oQv8ZU6R6dLA3nasi8ZrUnGHTq05lajRXOVWyntWq 8pSqVjcLS6yaEqzMRGdkw6rOY3ZVs1DV5lnHulZagnGxf3UrTIvqULjalaCzlehMI8rbgSJ1okIl KWA/alibwhaow42tT/PaWBu09oxq/UR0/p9bjOZ2kbFGwK511UBdLZI2FN/tbjRqKd7ymleK202v esN43va6d4rkfa985/uN+NL3vvit4jXzy9/+Vne//g2wgGmxAyMa+MAITrCCF8xgGfoiUg2OsIQn TOEKW1iC71MqhC/M4Q57+MMgVjARbxDiEpv4xChOMdGU4CcVu/jFMI5xhEdsAxnb+MY4zvH+HgwH Hfv4x0AOMu8ImAMhG/nISD5yEJLM5CY72cVLfrKUp0zlCUe5yljOspY3eOUte/nLYD4iDloc5jKb +cxpU6CGe4zmNrvZyyss8pvnTOcnd7nOeM6zj++s5z77Gco5IPOfB03oEMcZB4VOtKIv/syGDS/6 0ZBG8KGJ5OhIW/rSFJx0jTHN6U6H8AeeDrWozxfoSo/61Kg2mZpjIOhUu7rQNK7Bq2ddaB6/gda4 9nOsaZDrXuPZ1m7wtbDfvOsgmnrYyIZzhll97GQ7u8rFlsGzp61lYLeB2timcrRjkO1uO7kK3g43 ksEt7nIDmdzmTjeO0a3udsOY3e6ON4qtHQB52xvF20ZisO/NbxDnG3W3RuB6B07wHwQOwPvWXMEX znBIepDZbB7ygCdO8Wsg/NrgqbjGNw7ENQdc4Q0Puchp6Fo5S5zjKK94Elo98pa7vAQHN/kDU07z Aa+80i80bwH7beSYQ/zjGdI3fXfO/vMg+5zEAgf4fYle9B9DwSlCn68KjhSPMgFpVeKix3T6sfWq U4nrX/c61cXedbLPo+xZx5LWP3V1tGfd62Q/2NnNIw+32x3rce+62uEeEry3ne5zl5MRWN4/BRje 8NE4vBsQLxEU6B3wb4984NcekLJbHvJ857vb3/74zKN965evO91Bj/l8sJ30pod86CfP+k+t/vWl pzznVV/6zd/ngjK//RwYHwDeC0PxbfD9KjovetbL3viiJ37mi8/8zRMf9rKHft2XD3bUSz7yq2d+ 662vedpT//hp9z74k96ENNNB+G84PO/Vr4Der5/96Vf/4uEf/PbX//zAfz/w3a/4/v3z3/foJx8D kX3jd31Aon3XJ30FiH2jh3ncF35g13eu14AReIAJWHuxx4DL94CpN3kE+H1BdwSENycB6H7zV3/t 13/2l3/2BweMx4L3F4NyIH8mGAcviHgqKIPvx1YmwHbGt3cXyHVVh4B354FjJ3bgx4EPyIF5F4H2 0XbNN4EdmHoYaIRWOIDiB4TId3J7oDBQR4It6IIteIMxSIYyGH86OIYpGIY2uIY1KIZluIJyeIJ4 MDU+qIEVuIXWp4XJh3e2h4QbSIFGeITOl4HF94S2Jx5DWIhYSHuEGHYGSISC+H22d3SbBnIm8IZw GIec+Ib6B4NpqIltiIJqSINm/niD9GdNhEOAiViF0TeJQRiFJLGEsAiBsjiFWGh2kYh1foeA1ReI wBiJwfiBkXhzETdzM8iGdFiDpziHnciManiCJRiHZgiNnTiNfqB8eIiLvgiF2yiJIPh8WeiAsLiE IDiItfiDGViEgKiAtlh546iHGWiJLjCCPbSDnuiMzUiH+IiPKGgH+heK1jiQ+ciDJKCNxEiJ5Bh4 xOiO2ieOgwiO3XeOD8mEEsmNnkeLw+iK79iQ8/hwlHaMurd7NEiK0TiQ7BeGKSmQ/1gHAWmS+uiM /6eSyogHRxiIYad2aMKQC4l85fGId9iLV+eTgOeHkCiRWpiQBniTn0cglKeT/o4YlXd4jvTIaxn3 CdjIB1kpDE3XjSZme09Hfpl4CVupB2XZCkzHb38IYmD5BF/YQ4lwlncgl6yQlmppiB72h8YIdCNZ c13ZcyB5ichYcwmCAIZ5mIiZmIq5mItJmBa0lwkXgnD5mCTXhSewAAygJw10mC/HC1U5A+aHlTWJ fwZimAPQAKiJmvKQmqy5mqyZmq6ZDwZgmI6ZMEhgj2O5koJAl3SZPpWpByfAAKfZALE5nPOgmsNJ nMWJnPRgAAzQmbnwmdJ2lcmIhoHAm6PZDabJnMjJnMaZnMepnN5JDylTmxEBmRjHhZs4itSIg58I gCXpj9qpIOMZD97Znfcp/p7K2Q/laZ5XVGDUyZ4Cior8B40xyY8n6Q2mCZ7h2aAMap/6ORD96Z/e gJ71JpYwN5M0WZAoeZL9mJ2JYGw1VAKYGZ77+ZrciaInup/58JzQOQnSST+hiQc7+KHPWI3VGBEL 6qD5CaEsip8SSqFZBKCYmKHr6Z4IeqMymaMWl3P4U6IpCqE82qPfKZsL8KIN95aZCJ/xt6EdmqRK qgkiaolQuqJSupxUWp+PcqVYml64maG6OX9e2owlOZPL2Jsw9JslRwILoCevWZyxCZsNqqIJwqZt GgkxGnVaaqQuCaL/5aQZRKKZ6UCIeagwGpiyhqEkQKOOql+QapAjsACM/jmqpNqYIWKp1vWmmwqQ neqpUZenSpcJ+WNkLpeoLzCjQro6gKlxYameucoHpVqeR8ZxvTqYv6oHhqmZAXGY6Wl0G2ehuPoH eDpLDuAAwKog1Vqt8pCt2boxPeEAAJSt28qt+cCt5DoA5gqu6Kqu8aCucWCtv0qkxtql/idg1QoH 5ioH2Kqu2rqu8zCbFwoS/So/55qu7NquBouw5Mqv7cqF9+pfxdqX1imK/ZWuAfCwFwuvbmCa/dqx B+sxJPGx6wqu4lqyIquwHkuyA1uuA7uy6NqwL2usGstf0KqpI8Ch8Pee9Oql3xKr45UC3PoGGIux bcCx/Hq05BmwAeGy/iPbtAlbrk2LsieLslLLsC97sCdQrQRnq5MZmRJ7p3LooWILtlgUtG4wtDNb mA/gsVLLMiHBtCarsnI7EOLatv1Qt1WLtEgrB0SrB2jGtS2wqJtqo2B6pKM5ptPwFNkqtBrbtwkC ASPLtv76MG8rsnHrtEw7rkc7tyw7tXjbsPyatQ4AmmdWs74qp/vHpRSroa3qRGaLtnHQMOPKsiAr sJarrZf7ufRQt3H7uS57udsKs2nbBo7bMmYGuCwQrRO7vEx6htV0r9DbuGm7owhLu5Rru527sOlK tyn7tFGruecqvO3Kt8NrvGUWsU8RgKpLuBzas10rDWcRvRl7ttLb/jCSy7bXK7B3O7cma7vsaq7f q7uRe7AEDK5Za5Vmhr68or48m4p2uoyIC79Am6/Ea7YVPA/hG7luW7nfmrkMZgJaS7oJ7JYBap7F q68dcxf5q78h68EL9q6AgGamK5ljKQoR/LPbcsJzQL0kscLnJq9hhrw29KlG86quWsN9wMMS6sNO B8RgFrHHyk6gVJgIkCeH2Zy0qbRAdggyfJuVFsXmJEv6qphe+2NcfGZCfLM4Z8RDSnInhAAFJcJB xgN/i6kIPK+EMK1UtE6GyUYaM6F7MKyG0MUi+MWsWqesWggpqcda2bqHwMdtxCcAq3F1PEIXp8Vz 6cjLm8eaPAiM/vwHpmSamrRxlYx7iGazIuC8jRqfrLyMJNmGrMyCsayzMnjD7htSvrSgATVyhDx4 a7wtZymfhZuV2CjLZNu+wsd7tsxQ0CS7AaVXC1fKsPpzXnsWqaibwhyKW1nMOcq+2Xwgbswrl0S9 fmwAIkVw0myZubcH3Ay2rbzNyrjIZ/ih19zJhNBGSqwgcLxaA9bL4lPNQtfOYXp/8Gy4Momzo4mN y9w1rSQPkYwAC3DOA5fOwHnJynvMr1yg7avRiTyxoEiNLJnM9pxPCTAAa9QwdfQw9zRxFL2nSFek q+rAJDnL8Nmq6CfPohinMp26LbjQeeXHDqMnuyxy/rwEFy2a/qLwyZpASinTx6NccUXtWCJJxICg 1H5g1T7dQ9MlVESNxnZ8w0fdCVZtlogMxrHQ0nWoA4Krxu81plS9Co8Q1UJg1nTdamCWxvVY1xQq 11fQRGN9qkj01oWAAJtB2HRg2Ku2CHwNBKoIlzLtCdzMhvWayewMom6dAgdQnpktCFVCHg0CI5t9 JZAS115tyR4nrQmK1Pgn2b2JnZtwGW8A24FwGZ6iMpsh2xMq2zeD1o3NAx09oGHrnrL8nqVYgvRH 06jrhvnI0zyNCGYyI52d2QwS2qHNLecB2imz2aD92Q/DIUWiGWYSDottcDx0s8YttqV4zB8d2ahY kwRK0Akq/szK7D5cwRuEPZsM4imqkSe8odv11t+33S+wPeABft+J4iyJcstpwNvlPWaNmtEEqYne nNqjmLPufdB16o9/bQfQ/dlB0hz3cRmE7TG9oijfDSufneLfPSPdfR/h/Q3j7QO9DXPnXbgSjs3x DaLCjaQwOc8iXc+RGtgpsCH3/d9fhzC0jTD/fXa6TeABQOAy8t+dshmkfbxfracKnso1/ow3Xp0s 6eVfyuUZntCWTd9d0xwdUnb4fXtofiUuTtsofuLb/eT8PeIoXuVlhtcAMOMxPbYarboCqeE67ufs a4KC7spveNlzsiEdMi5FOx9vwOg9JuDN0Qar4eQiDuDU/jHlWX4GDB7kvp3J/ofjmwzkPk7mYE7q w4zIzX0JQcLfJl4gZ8IpVFfF3SISc54ZhD0dds4tz2INMd4DfM7W7qXoPVTFkV7FedIgyB7bSu4i 8tAhyj6bzF7tCdIhy37tG9sgeB7EV87Y8mXsPYgm5F7u5n7u5W6oil26XqzXvbHs8B7v8u4pRvTr 1fDpoFpq7u4HkzxfwS4FFCfuSGwLaPDvhbzvjmnwUAA4ePrXAs+oBO/pCu8LcfoNBX0JD7+pEbDx G+8GEYAJHP/xFW0Gbdbu+a7lFG4NFx+iZp4CIu/xbfDyiPDyMt/gX9Bm387GKLSlOT7qY87cwp3c HK2h/slNk8htkmkI9ICe8SNQ8zEf8gHQ8VHP8TE/9TQP9W9A81UP81pf8PjOT+RNmgM94f+YgwVq 9i8Jit8snzgatl9eCE6/9VIf9Vk/9Vxf93hP93pf9VoP7BN/A8OO8iF90Op9oGGe9n6+umy/pIw/ Pi0/JyHf9zI/+XtP95Sf9Vh/+R8v8l5f2tMcki2Wvj9vihcOpvvYoapOkMTtym3/9oANcCok8rKf 95Zf95cP83eP+5u/82PQZzZvlR299qV/jYZ/+sAd6DlunWQPCrNf+ZT//LTv/NJf+93QZ0mAx8i/ 6tl/+Ib/54Te+j6+/RsN93DQ/LdP/Xzv8TUP/U+P/vvVr2fXfzpFs76jb/SEe/qrP/g0bfRJf+i1 /PggAIgjEETnGahmurJt5Mav6b4tPdcq2fs/MCgcEgfGIzKpXDKbzic0KpUSq1aR0abdcrveLzgs HpPL5jNaqzOv0+63bSqf0+t26jUfzML7/j9goBcKYaHhIWKioqJg49cdZKTkJJKepY+RkOMmJyeR y5AjYdrapelpEaXqKisTapAXX+csba3tLe5s6y4v5dfrj2zuMHGx8TFnr/LyHPBP7ICz9DR1tfU1 drb2HnO399LvJfQ2ebn5OXq6+Tc7ezi1MLL8PH39fDs+c3q8fb//P0A4+Qby2hdNHTAGDhAybOjw /qEQghJXXRsH8ZKEBRc3cuyIbSJISe+m8Qto8iTKkyFX2jGY8iXMmPdY0pxi0CPOnDp3VqvpE4rB n0KHEi1q9Ggza9CQMm3q9ClUZiOlRa1q9SrWrJnQae3q9StYghW3TAgQ9izatGrtTL2ydC3cuHLP tgU29y7evFDHctHr9y9glnVfBS5s+PAyvlsQM27suM5gVI8nU658JKjlzJoBK9ay+TPou5FDdQlt +jRdL6beom7tGupoTaVf0659NDas2bZ38xasWpzu3sKHt8MNhDXx5MpbGX8WfDn06JCa+0Au/Tr2 J9R7WM/u/fuA7SS6gy8fXfwI8ubXE0efij38/uWY49PvPb8+ftqd4+TvT9v9EP4J2Np+Lgx4YGgA qocgg4gBmNsKDUqoV2kNTXjhXHtYiCGHamnIUIchnvVhNV30ICKKXu3xYBUpuogVieq8OGNUMU4j xhEH6LijETrmeECPO/qIxJA8DuCjkEMeaeSSQgbpZJJKSgnkEk7+SGWQPxKpZJNTbonlkloywWSY ZY7JZJRfYpnmk2pyKaaZbV4JJpxFJhlnmGyy6SaVevoJZ51gkumnlYSieUBfLL73Z5Zdvmlnn0Aa CqmRaUYJaaNJ7DmonV/ymWmTnuI555qRNjFpqYXe6Sipb5r56JRWikppp42iSueljka6aqV0/r6a aqy9qjqsqkAcVGIYmgpaKqhK7Npjs6OCCiuzoY7qZZ6pZopktdlqGWu0v9rqK6DRYrtttecGumWZ rs5qqrJiuqquuPOS26uz6XZ77bL5yovoYooGyG6ru5KZpaTt8irrtHdeajC/VUoKbL3dcvstxe5i W6vEh6p6qsUGH6xrv7R2PPGTwlp7q7LE0kopvwsDau+nJAdp7IYzo5ovty+rSXDKPcsqtL/xjtsl uklz3CnD6yr8hMvwSuz0nnyGPKe/UWPcatC+5spytvbK3HDRXZt9czAF8kCC0UlL6+mhTnA5N65L P9u20PiuzKi3Nit8r77hFk0z2W5zDHSw/gcTrne89D6NN8ptEzzyxvsSbq7Ux2KiYLJAi6vr1Ohq rTOUlcvZMo+5/t21yPCqjunJ+lK+8NCrNhw35oE6bPu/rYt6Nr1f0/6xtYgDW3fZoH+uY6K/feR5 5U27rTzS0O9e8r4/w1px47XjebHgxf+tscecbv97nOc/jjH5vZtfM93wD8/45XR7fb/87OqIs1Jc nEgjAJmyIufpwURsCyACizJAAz4vgQ70iY2kgaMHUtA3ASOgNSqoQZBE8Bwb/OBAOpgN/oCwhN6o UP/AYMIVSqV5DCyg/w7Iwhm2YoExvJGBaKhDVaAQITv8oSRE+IoJArGIdCgN57bwPyMy/hEPwUii FpbYxCk2wYZKpAYJqajFJPQQi51bhvDupjqr+Q51VzqjyooHJb+dzGpya5kbWcc1OeYICnUjV/Xk lLqqmXFZ1GrTGI8ER2FlbChIxCAwssiLIiGMSI6so7MiKUhIQouSuKLkqzDJSEw+spKefFvCOsnJ NYlSUO2y1STHlMpPzgxxmlRlnUSZyU0y8pLT0iQeQ9JFcihyF6SElikh2SdJPjKYq6ykLVcZymFq CpmsPGYqmYnHUHLymL9kpjKjKUxoOjKZ1dQmNqVJzG02s47D/OUkqelJaqLzmRb0DDp6qQxvBjOX XvtkO9f5SnM6E5b2JCY2VelNVl5z/pwDFWQuEVpOWeoznO58KDRNGdCIWpOf60woTXa5DXn24o7m s+emGHZPfe5zmSBz1zMpdqp91ixlPJvXQqfJ0m8WVKVVWulC01nRThpTnOj7iUa1wdFF5rSeOL3p SEu5U2dOtJhHtSREWVXNZDZVnbLknZsYeq9tFhSWNy0qMHMqVZI2NXwgCeoIc+gNejqVov4UazbZ ispy+lSr5PwqPrsZ037q1KAMzeYrt3pRcib1rix9lFKherqDvjMO8VRrN+SKz8LuNbEWPWw7MyvY vEKtsmHlqStTetVxalOYxoymZvEKWIKW67SlRa3lDNmXx0ZoreDaG1bFd0aCjsya/rBTZvl669Ld nklblgqp7dD0Lm0Rd49NE6mU6NhGM/7Oj4vtmfhIKb2MzjaFj9gieI9wyBc6Y6jhNSJah3hDLJwX vFaMYjba617+IeuKI5DvFt9rg/qqAL9aTC85/EtFIaKCiKy4Ixyrq7g9Sheua/wpcrWnR7Fdr3YV pjD6XnfbBcv0pdx88GSZy0fhelRjcTwdZ4vjwvXmwcCqsCrg8AZaNErznqe93FxnGt1vUrSeNV4t kAubz355Tq+lFLJ2RztTbirUsp9l7Shf644V2xeGVQaAL5dq5CaPFHnotLGSt2zSGZOZyWDW6ZdX m9Qu8zWvSUaqWCn7ZijT2cxa/r6ka/Ms5W/oFxTxbQWM4fzZLmM0oepE6WXHrFiv2rmZZb3zVCOt 5bhe1tGSC10k9RxlHgc6yppmbT69QeBTkBfQS36yonHZYbwiWNBc9mzspmkoRo/VrRFVHFjnzNNW F5fMkk1xmbH6ZWHPGKMFOQ4U9yvDF4v0q2OmLIqZXOsio7nNewarattKWqvams1hrvaHc2vW8Q35 24AbVLiV62Re5QNC5E0kZCdx47Y+W5LI+6uaHTxoOq8Z3x2eqC0Pmtm+AtypVQ2tpCtd7k2LtqTY hjSw8fFurqyCqvTuq5qJzGm6uhbcBdexvxmN2DIHecunTGyqGz635HX61wL3/myeO03SSvOZtvC9 L7ONSztkBqubs7ufcfO4WzFKD7p3+ykbrzvkj+bNfvbjuXVdOjETl07ERuewgqdu2uPxzrlYw4e7 WQzv2gqYiRMvL4vL3sSwX3ns/VU7esUuwbTDvYhsv7mV8Y7lugPx7sq2hIv5PsM08Ncsgt/h2d3+ d/YenoZ+9zMOyd54FiZevSqc/ODRoA3MzzAnnGdhOgL/eQ0SHjhXHr0JH7+C1dAd9R9U/doa6HoN bsS8swdg5Ttz+w3mfhu7pz1Ofl/B0H9RCglIgBGOj/wBHP8Iyne+8puf/OdPH/pLiD70o7987S+f +d1XAvenj/3sI0H72ad+/hLG7331h5/81q9++dGffum/3/vzR3/76W/++9u//vWn//rBn/Xl3/dJ X/utH/Vx3/fF3/l1HwG+HwBGQulF3ttNgQFeoPsh4AWOn/4toAZunwJ+IAg2AQHuXwA2IAiqHwqK H/6VYAeO4AreHwAm4AKaYAi+oArSoADGHwxqoABuIA2mIAsGIRGqoPg1YAx24A5KoNwJVbxFgRAy 3wAWoANW4Q96YASeoP0pYf+RIBVCIPJx4RZ6IANeXw1aIRfq4BXO3/9hYBm+YfOJoQ4CIROooRKm IRZu4Bp2of9FoBFKIRu24RJORxMqHuQxngWGoRTe4RcOogiCH/vd4AM6/sEMPqAchqEJIuEbDmEc WiECdmEWwmEVdqIM8iD2XeII0qEZkiIoYqIrcuIRnuABuqARYmIgbmII8mEkwF4AsN7lycEpqmEr +h8KkuEnPuIHEiMkmqIb9h8j/iELbmIyDuMY4uEZCmItyt8ktqItwl8oVh8HeiIrTqMCpmA4niM0 6mIWVuL+fSNkaJ7p6V0dPF8L2qAnOuM9mmEsuqEY1mEjAqEwjuMTVGIgNiM/XuItWuMtguEeBmAu uqMeUuM4rqMtGmQPgqExEuQyCmINIRsiwQMdoGIkMmMPUuQ5TiFGfqNGViM6AmQe5uA1euNIauE0 MmMZyp8uDiMOFmEz/m5kPbIjSYJjNz5kOzbiQobiSvbkLgZfSIpjTPphCyrjMdIkTPqgPvYhVFpl TZriQvJhRDZkNK5iQsYkLv5kPo6hF2LlGVJhOKJlTW7jIK5kWTIkJXie8D0Q8Z3eXToQL/qiPO5l AvVlPC7e3gFmAAmm7BnmjOTldykmjUxg3hGmYwIQYkbmc0wmikBmBmHmi9TeE3Jmh/SeX0omaKZI ZbZY65VmiJym4qlmZhai5TWma3KIZrbmbIYmbBZYat7mhLCmFcgEcAancA4ncXYCTxwncianci4n cx5ncT4ndEandErnaE6ndV4ndmanMVSndnand34neMIj4IUneZan/nmeZ3Omp3quJ3u2p3u+J3zG p3zOJ33Wp33eJ37mp35+wnn2p3/+Z3RyJ4AOKIEWqD0IqIEmqIIu6CwgKIM+KIRG6Bk4qIRWqIVe aOxZJoZuKIc+KIVKJwKEKAJ0KImW6EfupxUsAAMwgAEYAAMsAIzGqIzC6AjEaI3SKIpeAgXkKI/2 aAnIRIgugQEwgYgWqZGKqIkmKUp4hHciwC6MqJJGaXl+6HAG6S4YAJRKqZZ2ZznAhJUOQAWEaQUg gZiO6RGUaRKEKRJk6S1YgAVsqRu4KYMyKRnIqQrYaQDIKZ7m6Zvu6Z7yqZu+6Z0K6qDyqQvsKQI8 gBGUqZouKpo6/qqYkqmZGkGWBiqhHqqlXiqg4mmgroCd6mmm/umgdmqhemqfXuqfWuqmqqoNqGqo aqqhmuqocqqmimqotiqrAqqsGuqrwmqqdiqtrqqoCuus/iqpCuupguqtxuomlEOwFqqfCuqn+qq0 ViumliqiOimYTmqajmmkbuu2TmqjUiq2UuuuMuu0Euq0XmsXrCuzxqq74qq8tqu1foG7PuuvasGz omu1qmu9luoW2Gq9xiu9yuq+4iusvqvC2ml7pqu1Rmu56uvAourEuoCVjmu3OqrGguvGPsAFsCnA niuv1mqyVqzISmzE7irBnuywqmzCziuoymu+ziu0kuympmzI/tKsy/IrGAQrwspsws7srtLpGDhs zbLrzaIsvFKsqf7pxTKquJppo05t1B6BBIQo0mZtzF4rq7Zsy6YsxM4qFwhtwP6rF3StzZJtyG6t wZKq176swi5t2J6tv/Lswp5q2eps3AZClyor3iIr05Yt2mptwmpruD4qo2IApGIsxmZApb4sxOZr zL4t3Q6uyH6t2sLssuZtzrJtzr6r546s6HIu6bosyWaq4Lot6nZuyaqu3jJsR5gB2hLs3NKs59bu Chhuxh6uAWjA4u7umu7t2v5t24pt6Srt6A5vwWat0n6t7aatzeps6G5truot88pt4NItyuJu6LKu 9fItL82u/tni7rnebvZaLAKMK+J6a9UyLreSq70yreT2K+TCLc/WLuZG79iarfZ6b+ZGLvQaL/IO cMTu6/KyqwEnL/N+bXsmreUqL+neq/6iL9Sqr9Re8MYerppuwIjmb/nWLb/Wb/8urffu7/fubBjM La3yL8Ae7L8e6wnHrQR/LgHbrd0Oq9rC7npCMOieL6ZWb/XScAA4KdRK6plmcNSiKQd0MNxubrF+ sAjTKxDDsBBPsRQTb/ziKhWvrsQGMRevsAnvr6sCa92+6vH2cNMmcNKWMNFeZ4gOKaW+MR186RFg LZzeMXXyEpAa6RAjABwT6ZHSsR3jMSHbQgNHp+7GMZJu/gEfF7Ij00Ibl6ccx/EjV7J3Uql2NrIl b/J1YjInfzIo/0GXhjIp14OPYkMZ9Coai2/+Hqsrt67Aqm4Q/3C0vrKyQjEOm/ETV24tv+2tArAX 56oKP/DeqjIwz7ITr6oWrzAxG+goozEKk+8N+6z9jioPI228IiwIqzHLgnAEv7D94i/xujAEU/P1 Ei7XVjM5t/A2B62gnrLa9Oz5znAWp/O6Oq81C+85z6zRKnA9l/APH68HX+4486/5FrMPS6/8qnM7 A61D1zCBerJCIzALE7DfHm38VvT38jP9YnQK+3AsC3QTz3NB++9Cl67zirM+s7NJP3QM/+cz9/ID J3NL/k8uTetqsbqzSBcw3uIzOl8vFQP0ABvzFwdw8XYxF6O0GesyLSfw9MJyvcKzd9UpSVexuaaz 2Pp0UH+u0XJ0uVLvVl+zDHf1BE908XIvFoP1QR/wKjM0NB81XJ/zgMZ0VQuvwD70GMtzFKOzV2Pv Ww91WeO0RwvxX4N1N7c1Vp+sWQ825zo1Fvuz3km1IYqBSpOwYk9z0650Pkvzz7J0CHv2ThN2Z6+0 Sq8zZrO0NBN0Yh+waY+2XAMoXfO1LIe1MrMzVCM1/bayLTPzZ+c0W+/yFTOzW6v2MG+xcef1Zat2 2yY1DzN3UXOuZDdEKU+3PEQ3Q1A3dheDdSMESixy/nYr6XajnXD2gIqy6IvOKHprhAjY6HrjaHp8 N3xr92BWaSIPwB8rQSDnd3zvt3xvFEDU9ySALH9L6X4+Jx2vApYOuILXgkTbsDhv7upK85d+6+9K KsZyLPym8RgjM8UK803XtmCP9S+f9HLD8LLSdGWnMS5788iiron7rb+6OHNbNCuTMUXLRIObNkI/ 71/nrqJq8JkyapBTOIYPgIA39wS7dhjL7WuXNolbtkfnMAt7uGcDcBcHND1jc/2mdmFrdEDkeEeH 8FXTMPk+7RKo6fqGa5AHr1ITtAF37+uWbHJ3OWLj7E+vMZRrOGMfdCx3dJZ/8AindF37dD+AufHy /vZi33nuauuFb+y3Uu2aD4DHHvlb9zJxD3eJz7mTr/bKIrmxurPr9nWni69l3zVhi7lx/zShH+h8 y/PNKjlnM/WiL64FQ6qjV60RXO2Ry3Tg0u5tx3mL6zOv83lSn3ivG3QU27TmfnVeN3uEj/gs83g+ D6+x43j4zjYKK3ei5+6QP3ri0roRH4HjtrmoP/mSY/SMa7sCK3vBhu3KUm5W6y+VAy27QzacS3uI V7YO46fsYrtvK7q6c7sSUG2YtqjvHi7w1jFgU7vrxvVOO+xIy3Zie7C7O/deIzcuK/YMm/OyB3qM K/qq/0Pf+nuKo3ZC97EFYzCFozm3NrqAD7Py/ir5N1M7W1c8zvr6aYu1m4O2zm98GY+5oEMxyEe1 fp4BzAd8bUt4+hbxrWMwhhcxBy98XMN4jEc7iNdyzWfvvDM7xLN4amM9cLs5xpd416c1qM822dp8 TDT4PxDxo2YwmCJxt6vpEi+43TvCM9vDJBu5H9fBgfP93SdpgUMnH+89IAfymlJ64C/+hJ4yGAC4 JttAI4c35Ve+5aPyFxj+IJPB5Xe+518E44f+JrO96Jc+hpK+6ad+hKK+6re+gn4+7Me+7M8+7de+ 7d8+7ue+7u8+7/e+7/8+8Af/fXaA8Be/8R8/8ie/8i8/8ze/89++60e/ibK+9Fd/f1K/9Wd//ng+ P/d3P79rP/h7aKuHP/nDtPefP/qnv/qvP/u3v/u/vwiUv/xHNPzXv/0z5vyLgQJsQAbkf3FiPwgE 4kiW5omm6sq27gvHcLZtmYzn+s73/g/0AYbEotEYTCqXzKYqk5E4p9Sq9bo8arXYrvcLDovHPg+5 t00Tz+y2+w2Py39q9fyOz+v3fHr9DxgoOEhYaHiImKi4yNjo+AgZKTn512d5iZmpOUZZtPkJGioa 01l6OIqaqvpp2jqI8xH2EZtHK2M7hfsVSzvrhKuLErzJG+DaGTPrKzJMMtx8u1wCDTtC7VLMPK1i q3td/Z0CHa6d/evcAqwzrtRsztbajZ0r/hxEDiP/kk91b9IvHuAdE3Us/gGsl8RdQGPHGqZR12uZ soUBJVbk1c1iL3/MJl7sqPGjNI8TI5r0pm0hxpUblXnz5TJlTGcSYWZsOa3mSZA8VXr8eILkSJUy e2abKXOkRaJIkfIUahJkVKU7gf4U4TDrEYgUU3otRxFnuX3WvJqDuDHsNnlsy7rFua8Y2bhEg5ZN i/Idwbp80Z3tirBrxKKAfZr1ezexWL57C4P9evQxY8EotFoewnXo25JqfXLmdngu5c4x20rOzNRt asiq5T4rTRh2Y9N9Zd+lRpeyXKmjAf9lS/uvtbmfL35uCfv0sMuWuXb0rZt04WtpJyeO/h39dO/U u0Nvp3sTnfjF3VlrB99b2rbD0csLhx687m/Vw9Nvx45S8nMSzLXmc36edLQ5Vt171pGXnXWtaQeW aN7VtyBe7Yn3oILuUbjeaHsVaN91k8Hl4TP2iSZhfMHo0l9WTQElEm+RhbXUVy3qN9N/SdUEI4cU 4jUfWRW1p95wEuZYnlExDmbch0Fi+NOGQup1VVRG1fdflErx9mOS0lm1GYsjpOjQKmKOGYpBYYDZ EJlqrqnHVXmgmQibcs5JZ50rtGJnnnruiQOckcxTTR9LWjKoY2oWeoWZXvhZSQ8GGrogForKiCVo lK4AFaKBRZqOm8nct8M3CglJak+B/j6ZDn2dbugpFqf84COmquJxIj45+PhPrZfaBcSklv5KU4Qh 3ophqqciCeoV8RS1kpYs5fSsqU+FZyRJWl5bbbEslgRTtey05ilUNEXrJYFUTdislOU2ZdNL6nKa n6qZojqrlel6e5B9jNbxqVrvXQjvd8zKC1+CTr7G4cHDcqQtdPqxp+CUNN4W4MN2NVZhhnEBw058 45ql17CxOoztoqbsBvBqJAMXJbM1FqeygQNy5FLIFROYoXEKa3xbq551K+x5pSEMNKUz0+fUdNDO tytLRRsMarzy7GuHrSiPKHDG4z084IUO9kVzziYSzDPSHgYsqtJBfxjUbCSvnTPZ/mbfrJCuFT5q 98hWvGrrwN597TF+IiMWeIIXnz22eUwubjF6TRueeMRuY2y4tgnPzfbjGa0M9awdfsG3Pm891xau wrk5ZJMwA5y0tUuXatVRR44bo1TuXlr0u9eqvlOVOUpru5HQ4n4l7OEWV1Wl9pIusW8vJw+6KXX6 ymf1a1LdiJw+W8999dgz0n344rvxfflDjI9++tGbf4yjo65C/S/x3wJr3J7D8r76XeBpv95ta1qQ ZNXPC2nbFO/s9ySBiMNneWEYD/KGQHv4gX1UcyCnZNWrKsyPfhj0h+MEQ537OVBEDYNUv3bUhQ1S sH3J0MnH2BUv4+WOO0Bb3sc0/tQuasFQd9tq1/DKBbH8KFBjB0Qhy8TCLfVY63ZeSiKPnDOvKTVr dESCnSqW1bi1MbFrFMvcj0joL8U1kG71oNzRAraf6gSmcJG7WoSAwzMINqhtd9ONGrGzFv6scF9H A0/Seva0NuoMIx5sEuZ6J7LWrW6EJuRYkJz2qyM68nJz1MzPnqY1rC3pJjMsXCWDJ4098vFsQTQh KXfmxZw0DHBQOyPkGPmtuFGubGCTW4+o1MV6kRJr+4FYHWN1NVYxRJTI6FstP1g3xA1OOYwLI+cE yUoz7lKXWTMUMos1NgARMovcfCXalmlNKiruitJznSqr5C5qxW6GXzTV8XSE/jwXbcaFr4vdD91R POCNLDeoK2S0XKMjLhWSeECKYRQF2ssgDo0WxPST/oz50FFsEAYNhVNEMQXAi15ioi+oKJo0CtKQ BsGjaRKpSU8qA5LGSRWzlMU6NhVAYlCPo8BapSkxSib+iSEcLQUDGIGFq5qKroPE6mCuRJgQmFoM UHdSaejaZKxd+ZRXRPUfVU+Yr6IKdag3zeBVpxnVMeFJXCJJ3kHJSlZsrUhGBw3NEiWGVqo40lmk sZcOPfOdGt4IS/Ek1Vl058RSoRNfleJrSLgEPbQuxKlYfBCCIpfHOoJLgDJLpNb+Vc3Sze6Chvmc hsiYm7tV9pdgZdozFbOW/juijaGMLcXOHpuczsoTlIdcDKqiGaLkxLZmmUXtBdFZWanRMJ4AYs9f W0basdCuc6RFZEK/iZXWEgKrpnksLTtpyx3ZlrmtJJgnWTnH34KzuOhSW23MiyCqCpJ5ZNRizKaj RLhtorHZsS6D2is5COHsvt3928Ly61/x4tdoKOwvNXsL3fyut7mVy1IpbSFdZCjWX0VkGb3oqdZ+ +vM+u3XeE5HEu5dMaLn0ShLHPLdZhCJLjvA90enk2kN2KpKessvdJm8I4QhP4lRuoGkmFOVjC6L0 BDoWBD/iEOSNarUJSR7yGXTqZD0WecpUrnL2olwCK2t5y1xulFSzmotY/oqhy2Quc0VfajfERDJU FozhEpqM5Ti7yhAv/WoJkQrRcWpQznzWxFNXVeMWATRhNdSJi9+10Ceq+awh2V6fHw2HxhZpc140 7WiPaURrUlJJlzKzpz8dYc0m2NLc7WOmb0zbAX8J1KxuNTGDg1lo/rfBqIwvW8dLZFfretfY4+I1 ZS3G/WbMSaCdG6+PjWxJRKNbqrMjjNup4nv+r6BiM7Rgg9VVSGsbDH8OKZy3DW5lSS981Eu2uc+9 0nCre92RRre73w3veMt73vRGNrvvjW9O1Hvf8l5AAfgN8IALXAsSWMDAD47whCs83fluuMOn0O2H S3ziO4g4xS+OcRZYaDzjHO94dAvh8ZCL/OPTHbnJM77wlKt84CdvOcU37vKYb3vlNK+5zW+O85zr fOc877nPfw70oAt96EQvutGPjvSkK33pTG+6058O9ahLfepUr7rVr471rGt961zvute/Dvawi33s YA8BADs= -----------00000015.01C70A52-- -----------00000061.01C70A52-- From sip-bounces@ietf.org Fri Nov 17 10:45:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5sm-0001cp-SQ; Fri, 17 Nov 2006 10:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5sk-0001Zw-T6 for sip@ietf.org; Fri, 17 Nov 2006 10:43:58 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl5sf-0004Em-EX for sip@ietf.org; Fri, 17 Nov 2006 10:43:58 -0500 Received: from [10.10.16.240] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAHElQjJ005599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Nov 2006 08:47:27 -0600 In-Reply-To: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C27501E-1377-4484-AD0C-E6732F604E2D@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] issue with oubound and the used transport protocol Date: Fri, 17 Nov 2006 09:43:33 -0600 To: "Leis, Peter" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 17, 2006, at 7:59 AM, Leis, Peter wrote: > hi, > > after review of draft-ietf-sip-outbound-05 I have the following > questions related to the used transport protocol > > It appears that Outbound-05 does not allow to switch the transport > protocol over which SIP is used. Outbound-05 says that a User Agent > terminating SIP request has to be sent to the User Agent over the flow > on which the REGISTER was received. The definition of flow in > Outbound-05 includes also the transport protocol. Now there seems > to be > a problem when the REGISTER was sent over UDP and, at some point > later, > a SIP INVITE request is too long to be sent over UDP, so that it needs > to be sent over TCP (see RFC 3261 section 18.1.1). This seems not > possible with Outbound-05. The switchover from UDP to TCP is a strong > requirement and in case this is not supported the usability of the > draft > seems to be rather restricted. A UA that is expecting to engage in this behavior would need to establish TCP and UDP bindings via outbound registration. I suppose one could extend the system to add a management message that would tell a UA that had registered using UDP to build up a new registration using TCP, but we don't have anything quite like this now. There have been some suggestions from the systems management people that there would be interest in using SIP to tell a UA to establish a "management connection" on demand, and what you're suggesting is fairly similar. Or we could just deprecate UDP. Folks know where I stand on that one . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 10:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl62T-0006p1-IP; Fri, 17 Nov 2006 10:54:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl62R-0006or-Lq for sip@ietf.org; Fri, 17 Nov 2006 10:53:59 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl62N-0005Kn-9S for sip@ietf.org; Fri, 17 Nov 2006 10:53:59 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kAHFrU216625; Fri, 17 Nov 2006 07:53:30 -0800 In-Reply-To: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 17 Nov 2006 07:53:38 -0800 To: "Leis, Peter" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org Subject: [Sip] Re: issue with oubound and the used transport protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Peter, The primary motivator for outbound is traversal of NATs and firewalls. There is no technical way that an inbound TCP connection through these NATs would work. However, outbound allows multiple flows to be established. A UA could establish both a UDP flow and a TCP flow to allow for switchover. I will point out that the initially the outbound spec only addressed stream-oriented flows. thanks, -rohan On Nov 17, 2006, at 5:59, Leis, Peter wrote: > hi, > > after review of draft-ietf-sip-outbound-05 I have the following > questions related to the used transport protocol > > It appears that Outbound-05 does not allow to switch the transport > protocol over which SIP is used. Outbound-05 says that a User Agent > terminating SIP request has to be sent to the User Agent over the flow > on which the REGISTER was received. The definition of flow in > Outbound-05 includes also the transport protocol. Now there seems to be > a problem when the REGISTER was sent over UDP and, at some point later, > a SIP INVITE request is too long to be sent over UDP, so that it needs > to be sent over TCP (see RFC 3261 section 18.1.1). This seems not > possible with Outbound-05. The switchover from UDP to TCP is a strong > requirement and in case this is not supported the usability of the > draft > seems to be rather restricted. > > > Peter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 10:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl61o-0006KP-7L; Fri, 17 Nov 2006 10:53:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl61m-0006KA-Ke for sip@ietf.org; Fri, 17 Nov 2006 10:53:18 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl61a-0005Ez-4A for sip@ietf.org; Fri, 17 Nov 2006 10:53:18 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 1CEBA7401B; Fri, 17 Nov 2006 16:52:57 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18294-01-71; Fri, 17 Nov 2006 16:52:56 +0100 (CET) Received: from [193.11.30.71] (dhcp-wavelan-vo-71.publik.su.se [193.11.30.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 264D87417A; Fri, 17 Nov 2006 16:52:47 +0100 (CET) Message-ID: <455DDABE.3010102@it.su.se> Date: Fri, 17 Nov 2006 16:52:30 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] issue with oubound and the used transport protocol References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> <5C27501E-1377-4484-AD0C-E6732F604E2D@softarmor.com> In-Reply-To: <5C27501E-1377-4484-AD0C-E6732F604E2D@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.645 tagged_above=-99 required=7 tests=[AWL=0.020, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip@ietf.org, fluffy@cisco.com, "Leis, Peter" , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: ... > Or we could just deprecate UDP. Folks know where I stand on that one . . . To me it sounds like we have to, at least for UACs using Outbound. Let's do it! ;) /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 10:59:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl66f-0002Ti-GL; Fri, 17 Nov 2006 10:58:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl66d-0002T4-Jw for sip@ietf.org; Fri, 17 Nov 2006 10:58:19 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl668-0005mx-E2 for sip@ietf.org; Fri, 17 Nov 2006 10:58:19 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAHFveS27554; Fri, 17 Nov 2006 10:57:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Fri, 17 Nov 2006 09:57:40 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111820D9A@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A5C9FC0@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: New work: Option-tag for ICE Thread-Index: AccKIQgFSWr2LJj1RBON+01ev46ZcQAP3ukw From: "Brian Stucker" To: "Elwell, John" , "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Friday, November 17, 2006 2:13 AM > To: Jonathan Rosenberg; Drage, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Re: New work: Option-tag for ICE >=20 > =20 >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: 13 November 2006 16:48 > > To: Drage, Keith (Keith) > > Cc: IETF SIP List > > Subject: [Sip] Re: New work: Option-tag for ICE > >=20 > > The semantics for the option tag are the same as for any=20 > other option=20 > > tag - it means that ICE is supported. > >=20 > > ICE is normally signaled through SDP attributes, and there=20 > is no need=20 > > for an option tag for the "normal" call flows. However, we ran into=20 > > some issues with offerless INVITEs. In particular, it would=20 > be really,=20 > > really helpful for a UA to construct an offer in a 18x or=20 > 2xx based on=20 > > knowledge of whether the UA that sent the INVITE supports=20 > ICE. If they=20 > > don't, there is no need to gather candidates in=20 > constructing an offer=20 > > in the response. > [JRE] Of course this doesn't help if the offerless INVITE=20 > request came from a B2BUA that does not handle SDP/media. The=20 > B2BUA might not know whether the UA to which the SDP offer=20 > will be sent supports ICE or not. So the absence of=20 > Supported: ice would not necessarily be safe grounds for=20 > skipping ICE stuff. >=20 > John >=20 You could make the same case for any options tag. For instance, some B2BUA's strip out the 100rel tag from the supported header because they want to muck with the early media being generated, and don't want the hassle of having to deal with PRACK on one side of the call, and not on the other side. Just because there's something in the middle that may strip the options tag doesn't mean that it is of no utility. There's really no reason for a B2BUA to strip out the ice option tag given all the backoff logic built into the draft when the other side appears to not support ICE. If the B2BUA really didn't want ICE to run, it would also be messing with the SDP crossing through it too. So where's the harm? Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 11:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl685-0002t1-Go; Fri, 17 Nov 2006 10:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl683-0002s3-Iz for sip@ietf.org; Fri, 17 Nov 2006 10:59:47 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl67o-0005zY-Az for sip@ietf.org; Fri, 17 Nov 2006 10:59:47 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAHFxMb22566; Fri, 17 Nov 2006 10:59:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Fri, 17 Nov 2006 09:59:19 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111820DA8@zrc2hxm2.corp.nortel.com> In-Reply-To: <4558A1CB.7060905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: New work: Option-tag for ICE Thread-Index: AccHRDHtlJyBp68BTuu54aLYZ2MRuwDHQlOw From: "Brian Stucker" To: "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think the idea of having an option tag in the REGISTER is a good idea. It may be helpful when the network is trying to initiate a call to the client. Regards, Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, November 13, 2006 10:48 AM > To: Drage, Keith (Keith) > Cc: IETF SIP List > Subject: [Sip] Re: New work: Option-tag for ICE >=20 > The semantics for the option tag are the same as for any=20 > other option tag - it means that ICE is supported. >=20 > ICE is normally signaled through SDP attributes, and there is=20 > no need for an option tag for the "normal" call flows.=20 > However, we ran into some issues with offerless INVITEs. In=20 > particular, it would be really, really helpful for a UA to=20 > construct an offer in a 18x or 2xx based on knowledge of=20 > whether the UA that sent the INVITE supports ICE. If they=20 > don't, there is no need to gather candidates in constructing=20 > an offer in the response. >=20 > Another use case that was suggested was to place the option=20 > tag in a REGISTER. This would inform the "network" about=20 > whether the UA supports ICE, and can be helpful in some of=20 > the backwards-compatibility techniques that people are looking at. >=20 > Thanks, > Jonathan R. >=20 > Drage, Keith (Keith) wrote: >=20 > > (As SIP WG chair) > >=20 > > As part of the ICE discussion in MMUSIC, it has been=20 > identified that=20 > > there is a need for an option tag. RFC 3427 says that documents=20 > > specifying these need to be presented to IESG by SIP. Rather than=20 > > transfer the entirety of ICE back to SIP, the proposal is=20 > to create a=20 > > separate draft that specifies this option tag and pursue=20 > this in SIP. > >=20 > > I would appreciate if Jonathan would post to this list a=20 > some idea of=20 > > the semantics of the new option tag. > >=20 > > The intention of the SIP WG chairs is therefore to request=20 > the ADs to=20 > > approve a new milestone in this area. > >=20 > > Therefore does anyone in the SIP WG have an issue with the=20 > creation of=20 > > a new WG item that specifies such a new option-tag. This is=20 > intended=20 > > to be a fairly short term activity (as ICE is regarded as=20 > pretty much > > finished) so please respond quickly. > >=20 > > Regards > >=20 > > Keith > >=20 > > Keith Drage > > drage@lucent.com > > tel: +44 1793 776249 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 12:21:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Ll-0007pU-JU; Fri, 17 Nov 2006 12:18:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Lj-0007nB-RQ for sip@ietf.org; Fri, 17 Nov 2006 12:17:59 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7Jv-0006dt-PM for sip@ietf.org; Fri, 17 Nov 2006 12:16:12 -0500 Received: (qmail 4272 invoked by uid 0); 17 Nov 2006 17:15:35 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Nov 2006 17:15:35 -0000 Message-ID: <001801c70a6c$06873b20$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Stucker" , "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" References: <6FC4416DDE56C44DA0AEE67BC7CA437111820DA8@zrc2hxm2.corp.nortel.com> Subject: Re: [Sip] Re: New work: Option-tag for ICE Date: Fri, 17 Nov 2006 18:15:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In that case, how about a callee capability instead / in addition (RFC3840)? i.e. a UA would form its Contact as: Contact: ;+sip.ice Regards, Jeroen Brian Stucker wrote: > I think the idea of having an option tag in the REGISTER is a good > idea. It may be helpful when the network is trying to initiate a call > to the client. > > Regards, > Brian > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Monday, November 13, 2006 10:48 AM >> To: Drage, Keith (Keith) >> Cc: IETF SIP List >> Subject: [Sip] Re: New work: Option-tag for ICE >> >> The semantics for the option tag are the same as for any >> other option tag - it means that ICE is supported. >> >> ICE is normally signaled through SDP attributes, and there is >> no need for an option tag for the "normal" call flows. >> However, we ran into some issues with offerless INVITEs. In >> particular, it would be really, really helpful for a UA to >> construct an offer in a 18x or 2xx based on knowledge of >> whether the UA that sent the INVITE supports ICE. If they >> don't, there is no need to gather candidates in constructing >> an offer in the response. >> >> Another use case that was suggested was to place the option >> tag in a REGISTER. This would inform the "network" about >> whether the UA supports ICE, and can be helpful in some of >> the backwards-compatibility techniques that people are looking at. >> >> Thanks, >> Jonathan R. >> >> Drage, Keith (Keith) wrote: >> >>> (As SIP WG chair) >>> >>> As part of the ICE discussion in MMUSIC, it has been >> identified that >>> there is a need for an option tag. RFC 3427 says that documents >>> specifying these need to be presented to IESG by SIP. Rather than >>> transfer the entirety of ICE back to SIP, the proposal is >> to create a >>> separate draft that specifies this option tag and pursue >> this in SIP. >>> >>> I would appreciate if Jonathan would post to this list a >> some idea of >>> the semantics of the new option tag. >>> >>> The intention of the SIP WG chairs is therefore to request >> the ADs to >>> approve a new milestone in this area. >>> >>> Therefore does anyone in the SIP WG have an issue with the >> creation of >>> a new WG item that specifies such a new option-tag. This is intended >>> to be a fairly short term activity (as ICE is regarded as >> pretty much >>> finished) so please respond quickly. >>> >>> Regards >>> >>> Keith >>> >>> Keith Drage >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 12:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Om-00012E-3n; Fri, 17 Nov 2006 12:21:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Ok-000127-MT for sip@ietf.org; Fri, 17 Nov 2006 12:21:06 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7Og-0007L4-7O for sip@ietf.org; Fri, 17 Nov 2006 12:21:06 -0500 Received: (qmail 19453 invoked by uid 0); 17 Nov 2006 17:22:08 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Nov 2006 17:22:08 -0000 Message-ID: <002f01c70a6c$be4c0fb0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Leis, Peter" References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 17 Nov 2006 18:20:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The outbound draft needs to say: "if a UA establishes a flow using an unreliable transport, it MUST also establish one over a reliable transport" (to support switch over). Moreover, I would suggest to add "it is RECOMMENDED that the UA establishes a flow using a reliable transport" Regards, Jeroen Rohan Mahy wrote: > Hi Peter, > > The primary motivator for outbound is traversal of NATs and firewalls. > There is no technical way that an inbound TCP connection through these > NATs would work. However, outbound allows multiple flows to be > established. A UA could establish both a UDP flow and a TCP flow to > allow for switchover. > > I will point out that the initially the outbound spec only addressed > stream-oriented flows. > > thanks, > -rohan > > On Nov 17, 2006, at 5:59, Leis, Peter wrote: >> hi, >> >> after review of draft-ietf-sip-outbound-05 I have the following >> questions related to the used transport protocol >> >> It appears that Outbound-05 does not allow to switch the transport >> protocol over which SIP is used. Outbound-05 says that a User Agent >> terminating SIP request has to be sent to the User Agent over the >> flow on which the REGISTER was received. The definition of flow in >> Outbound-05 includes also the transport protocol. Now there seems to >> be a problem when the REGISTER was sent over UDP and, at some point >> later, a SIP INVITE request is too long to be sent over UDP, so that >> it needs to be sent over TCP (see RFC 3261 section 18.1.1). This >> seems not possible with Outbound-05. The switchover from UDP to TCP >> is a strong requirement and in case this is not supported the >> usability of the draft >> seems to be rather restricted. >> >> >> Peter > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 12:29:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7UK-0003uF-Fj; Fri, 17 Nov 2006 12:26:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7UI-0003uA-Q9 for sip@ietf.org; Fri, 17 Nov 2006 12:26:50 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7UC-0007tA-9b for sip@ietf.org; Fri, 17 Nov 2006 12:26:50 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAHHQAM05529; Fri, 17 Nov 2006 12:26:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Fri, 17 Nov 2006 11:26:08 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111820F96@zrc2hxm2.corp.nortel.com> In-Reply-To: <001801c70a6c$06873b20$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: New work: Option-tag for ICE Thread-Index: AccKbChDYMiS3WEKQXy0pSojfHB84gAATw7g From: "Brian Stucker" To: "Jeroen van Bemmel" , "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Makes sense to me. Regards, Brian=20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Friday, November 17, 2006 11:16 AM > To: Stucker, Brian (RICH1:AR00); Jonathan Rosenberg; Drage,=20 > Keith (Keith) > Cc: IETF SIP List > Subject: Re: [Sip] Re: New work: Option-tag for ICE >=20 > In that case, how about a callee capability instead / in=20 > addition (RFC3840)? > i.e. a UA would form its Contact as: >=20 > Contact: ;+sip.ice >=20 > Regards, > Jeroen >=20 >=20 > Brian Stucker wrote: > > I think the idea of having an option tag in the REGISTER is a good=20 > > idea. It may be helpful when the network is trying to=20 > initiate a call=20 > > to the client. > >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Monday, November 13, 2006 10:48 AM > >> To: Drage, Keith (Keith) > >> Cc: IETF SIP List > >> Subject: [Sip] Re: New work: Option-tag for ICE > >>=20 > >> The semantics for the option tag are the same as for any=20 > other option=20 > >> tag - it means that ICE is supported. > >>=20 > >> ICE is normally signaled through SDP attributes, and there=20 > is no need=20 > >> for an option tag for the "normal" call flows. > >> However, we ran into some issues with offerless INVITEs. In=20 > >> particular, it would be really, really helpful for a UA to=20 > construct=20 > >> an offer in a 18x or 2xx based on knowledge of whether the UA that=20 > >> sent the INVITE supports ICE. If they don't, there is no need to=20 > >> gather candidates in constructing an offer in the response. > >>=20 > >> Another use case that was suggested was to place the=20 > option tag in a=20 > >> REGISTER. This would inform the "network" about whether the UA=20 > >> supports ICE, and can be helpful in some of the=20 > >> backwards-compatibility techniques that people are looking at. > >>=20 > >> Thanks, > >> Jonathan R. > >>=20 > >> Drage, Keith (Keith) wrote: > >>=20 > >>> (As SIP WG chair) > >>>=20 > >>> As part of the ICE discussion in MMUSIC, it has been > >> identified that > >>> there is a need for an option tag. RFC 3427 says that documents=20 > >>> specifying these need to be presented to IESG by SIP. Rather than=20 > >>> transfer the entirety of ICE back to SIP, the proposal is > >> to create a > >>> separate draft that specifies this option tag and pursue > >> this in SIP. > >>>=20 > >>> I would appreciate if Jonathan would post to this list a > >> some idea of > >>> the semantics of the new option tag. > >>>=20 > >>> The intention of the SIP WG chairs is therefore to request > >> the ADs to > >>> approve a new milestone in this area. > >>>=20 > >>> Therefore does anyone in the SIP WG have an issue with the > >> creation of > >>> a new WG item that specifies such a new option-tag. This=20 > is intended=20 > >>> to be a fairly short term activity (as ICE is regarded as > >> pretty much > >>> finished) so please respond quickly. > >>>=20 > >>> Regards > >>>=20 > >>> Keith > >>>=20 > >>> Keith Drage > >>> drage@lucent.com > >>> tel: +44 1793 776249 > >>>=20 > >>=20 > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 12:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7j5-0003nd-Il; Fri, 17 Nov 2006 12:42:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7j4-0003nI-6b for sip@ietf.org; Fri, 17 Nov 2006 12:42:06 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7j0-0001EY-PB for sip@ietf.org; Fri, 17 Nov 2006 12:42:06 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8V0008PYI1T8@siemenscomms.co.uk> for sip@ietf.org; Fri, 17 Nov 2006 17:42:01 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LHDYQJ>; Fri, 17 Nov 2006 17:41:52 +0000 Content-return: allowed Date: Fri, 17 Nov 2006 17:41:51 +0000 From: "Elwell, John" Subject: RE: [Sip] Re: New work: Option-tag for ICE To: Brian Stucker , Jonathan Rosenberg , "Drage, Keith (Keith)" Message-id: <50B1CBA96870A34799A506B2313F26670A61122C@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, You miss my point. I am not talking about a B2BUA stripping an option tag from a received INVITE request before forwarding the request. I am talking about a B2BUA originating an INVITE request (during a 3PCC make call situation). In this case the B2BUA has no grounds on which to include the option tag. John > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: 17 November 2006 15:58 > To: Elwell, John; Jonathan Rosenberg; Drage, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Friday, November 17, 2006 2:13 AM > > To: Jonathan Rosenberg; Drage, Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > > > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > Sent: 13 November 2006 16:48 > > > To: Drage, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: [Sip] Re: New work: Option-tag for ICE > > > > > > The semantics for the option tag are the same as for any > > other option > > > tag - it means that ICE is supported. > > > > > > ICE is normally signaled through SDP attributes, and there > > is no need > > > for an option tag for the "normal" call flows. However, > we ran into > > > some issues with offerless INVITEs. In particular, it would > > be really, > > > really helpful for a UA to construct an offer in a 18x or > > 2xx based on > > > knowledge of whether the UA that sent the INVITE supports > > ICE. If they > > > don't, there is no need to gather candidates in > > constructing an offer > > > in the response. > > [JRE] Of course this doesn't help if the offerless INVITE > > request came from a B2BUA that does not handle SDP/media. The > > B2BUA might not know whether the UA to which the SDP offer > > will be sent supports ICE or not. So the absence of > > Supported: ice would not necessarily be safe grounds for > > skipping ICE stuff. > > > > John > > > > You could make the same case for any options tag. For instance, some > B2BUA's strip out the 100rel tag from the supported header > because they > want to muck with the early media being generated, and don't want the > hassle of having to deal with PRACK on one side of the call, > and not on > the other side. > > Just because there's something in the middle that may strip > the options > tag doesn't mean that it is of no utility. There's really no > reason for > a B2BUA to strip out the ice option tag given all the backoff logic > built into the draft when the other side appears to not > support ICE. If > the B2BUA really didn't want ICE to run, it would also be messing with > the SDP crossing through it too. So where's the harm? > > Regards, > Brian > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 13:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl86H-0008M4-Pg; Fri, 17 Nov 2006 13:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl86F-0008Ll-T4 for sip@ietf.org; Fri, 17 Nov 2006 13:06:03 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl86B-0004HR-Fd for sip@ietf.org; Fri, 17 Nov 2006 13:06:03 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kAHHwOm19620; Fri, 17 Nov 2006 12:58:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Fri, 17 Nov 2006 12:05:20 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111821048@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A61122C@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: New work: Option-tag for ICE Thread-Index: AccKb8GuuXaI51HIRFG0uZCGmg1rKQAAfXzw From: "Brian Stucker" To: "Elwell, John" , "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, Ah, I wasn't thinking about 3PCC in my comment.=20 If there's a tag in the registered contact for the UA that the offerless INVITE is for though, then the INVITE going out could have the option tag in it (as the B2BUA would know something about the UA it's initiating 3PCC for). If we allowed the Supported header to be in responses, then you could even let the option-tag flow across the B2BUA as part of the 3PCC setup. As an aside, why on earth do we not allow the Supported header in a response other than 2xx (looking at 3261)? Regards, Brian > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Friday, November 17, 2006 11:42 AM > To: Stucker, Brian (RICH1:AR00); Jonathan Rosenberg; Drage,=20 > Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Re: New work: Option-tag for ICE >=20 > Brian, >=20 > You miss my point. I am not talking about a B2BUA stripping=20 > an option tag from a received INVITE request before=20 > forwarding the request. I am talking about a B2BUA=20 > originating an INVITE request (during a 3PCC make call=20 > situation). In this case the B2BUA has no grounds on which to=20 > include the option tag. >=20 > John=20 >=20 > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: 17 November 2006 15:58 > > To: Elwell, John; Jonathan Rosenberg; Drage, Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Re: New work: Option-tag for ICE > >=20 > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Friday, November 17, 2006 2:13 AM > > > To: Jonathan Rosenberg; Drage, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > Sent: 13 November 2006 16:48 > > > > To: Drage, Keith (Keith) > > > > Cc: IETF SIP List > > > > Subject: [Sip] Re: New work: Option-tag for ICE > > > >=20 > > > > The semantics for the option tag are the same as for any > > > other option > > > > tag - it means that ICE is supported. > > > >=20 > > > > ICE is normally signaled through SDP attributes, and there > > > is no need > > > > for an option tag for the "normal" call flows. However, > > we ran into > > > > some issues with offerless INVITEs. In particular, it would > > > be really, > > > > really helpful for a UA to construct an offer in a 18x or > > > 2xx based on > > > > knowledge of whether the UA that sent the INVITE supports > > > ICE. If they > > > > don't, there is no need to gather candidates in > > > constructing an offer > > > > in the response. > > > [JRE] Of course this doesn't help if the offerless INVITE request=20 > > > came from a B2BUA that does not handle SDP/media. The B2BUA might=20 > > > not know whether the UA to which the SDP offer will be=20 > sent supports=20 > > > ICE or not. So the absence of > > > Supported: ice would not necessarily be safe grounds for skipping=20 > > > ICE stuff. > > >=20 > > > John > > >=20 > >=20 > > You could make the same case for any options tag. For=20 > instance, some=20 > > B2BUA's strip out the 100rel tag from the supported header because=20 > > they want to muck with the early media being generated, and=20 > don't want=20 > > the hassle of having to deal with PRACK on one side of the=20 > call, and=20 > > not on the other side. > >=20 > > Just because there's something in the middle that may strip the=20 > > options tag doesn't mean that it is of no utility. There's=20 > really no=20 > > reason for a B2BUA to strip out the ice option tag given all the=20 > > backoff logic built into the draft when the other side=20 > appears to not=20 > > support ICE. If the B2BUA really didn't want ICE to run, it=20 > would also=20 > > be messing with the SDP crossing through it too. So where's=20 > the harm? > >=20 > > Regards, > > Brian > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 15:32:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAKJ-0004NW-GA; Fri, 17 Nov 2006 15:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlAKI-0004Lh-9L for sip@ietf.org; Fri, 17 Nov 2006 15:28:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlAKG-00070W-W1 for sip@ietf.org; Fri, 17 Nov 2006 15:28:42 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2006 12:28:39 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAHKSdu7016499; Fri, 17 Nov 2006 15:28:39 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAHKSdDM008977; Fri, 17 Nov 2006 15:28:39 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 15:28:39 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 15:28:38 -0500 Message-ID: <455E1B76.50104@cisco.com> Date: Fri, 17 Nov 2006 15:28:38 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> <4558B4CE.1000000@cisco.com> <455A7D8A.5080001@cisco.com> <86velh43c8.fsf@delta.rtfm.com> <455B6306.2000508@cisco.com> <86irhgcs93.fsf@raman.networkresonance.com> In-Reply-To: <86irhgcs93.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 20:28:38.0934 (UTC) FILETIME=[F701E360:01C70A86] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1152; t=1163795319; x=1164659319; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Revison=20of=20WGLC=20on=20draft-ietf-sip-gru u |Sender:=20 |To:=20EKR=20; bh=o75pdU4tqtwl0VzIP7txbaeZKZF5TAxWAi7QAOcq6rI=; b=dJhUmoPAf3idbumy06l6Dk9v4SnvglBaqoini84FTCkRzNSZr5lZzaVB2yCllSuSLkB7ktnP vzPFtkYk3aqeMkgutin/h1LKrWhPaf3ZBP2zB/0MkVAGHNBaEpy3SWNN; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: >>> The problem isn't primarily that they're not opposites, but rather >>> that they're orthogonal properties and therefore don't divide >>> the space. Why can't you have a temporary public gruu? >> To me, "public" was trying to summarize two key properties: >> >> 1. relative long lived-ness >> 2. correlatable to the AOR >> >> with that notion of "public", a temporary public gruu isn't sensible. > > Sure, but I don't think that's the connotation it actually has... IMO we won't find any terms with names that are acceptably short and memorable and have precisely the correct connotation for everybody. While the names clearly are intended to have some meaningful connotation, when you get down to the details it is the formal definition in the spec that matters. I don't think the current names are going to cause anybody to make some huge mistake, so I think they are good enough. If there is a decision to change them, then I think we will either spend a bunch of time just arguing about what name to use, or else we will pick other names that have other problems, or both. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 17 21:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlG50-0007iE-AJ; Fri, 17 Nov 2006 21:37:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlG4y-0007hv-9F for sip@ietf.org; Fri, 17 Nov 2006 21:37:16 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlG4s-0005QW-Hz for sip@ietf.org; Fri, 17 Nov 2006 21:37:16 -0500 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id A1CF01E4; Fri, 17 Nov 2006 21:37:03 -0500 From: "Hadriel Kaplan" To: "'Brian Stucker'" , "'Jonathan Rosenberg'" , "'Drage, Keith \(Keith\)'" Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Fri, 17 Nov 2006 21:37:03 -0500 Message-ID: <00e001c70aba$6eb10c00$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccHRDHtlJyBp68BTuu54aLYZ2MRuwDHQlOwABYx26A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111820DA8@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, I agree - I specifically asked for this in the WG meeting. I think it will help for mixed ICE/non-ICE networks. -hadriel > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Friday, November 17, 2006 10:59 AM > To: Jonathan Rosenberg; Drage, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > I think the idea of having an option tag in the REGISTER is a good idea. > It may be helpful when the network is trying to initiate a call to the > client. > > Regards, > Brian > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Monday, November 13, 2006 10:48 AM > > To: Drage, Keith (Keith) > > Cc: IETF SIP List > > Subject: [Sip] Re: New work: Option-tag for ICE > > > > The semantics for the option tag are the same as for any > > other option tag - it means that ICE is supported. > > > > ICE is normally signaled through SDP attributes, and there is > > no need for an option tag for the "normal" call flows. > > However, we ran into some issues with offerless INVITEs. In > > particular, it would be really, really helpful for a UA to > > construct an offer in a 18x or 2xx based on knowledge of > > whether the UA that sent the INVITE supports ICE. If they > > don't, there is no need to gather candidates in constructing > > an offer in the response. > > > > Another use case that was suggested was to place the option > > tag in a REGISTER. This would inform the "network" about > > whether the UA supports ICE, and can be helpful in some of > > the backwards-compatibility techniques that people are looking at. > > > > Thanks, > > Jonathan R. > > > > Drage, Keith (Keith) wrote: > > > > > (As SIP WG chair) > > > > > > As part of the ICE discussion in MMUSIC, it has been > > identified that > > > there is a need for an option tag. RFC 3427 says that documents > > > specifying these need to be presented to IESG by SIP. Rather than > > > transfer the entirety of ICE back to SIP, the proposal is > > to create a > > > separate draft that specifies this option tag and pursue > > this in SIP. > > > > > > I would appreciate if Jonathan would post to this list a > > some idea of > > > the semantics of the new option tag. > > > > > > The intention of the SIP WG chairs is therefore to request > > the ADs to > > > approve a new milestone in this area. > > > > > > Therefore does anyone in the SIP WG have an issue with the > > creation of > > > a new WG item that specifies such a new option-tag. This is > > intended > > > to be a fairly short term activity (as ICE is regarded as > > pretty much > > > finished) so please respond quickly. > > > > > > Regards > > > > > > Keith > > > > > > Keith Drage > > > drage@lucent.com > > > tel: +44 1793 776249 > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 18 00:15:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlIVz-0007EU-7i; Sat, 18 Nov 2006 00:13:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlIVx-0007D2-DS for sip@ietf.org; Sat, 18 Nov 2006 00:13:17 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlIVu-0002AO-L9 for sip@ietf.org; Sat, 18 Nov 2006 00:13:17 -0500 Received: from [192.168.1.12] (cpe-24-160-121-70.houston.res.rr.com [24.160.121.70]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAI4Gx1a009010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Nov 2006 22:17:02 -0600 In-Reply-To: <455E1B76.50104@cisco.com> References: <5D1A7985295922448D5550C94DE291807B5930@DEEXC1U01.de.lucent.com> <4558B4CE.1000000@cisco.com> <455A7D8A.5080001@cisco.com> <86velh43c8.fsf@delta.rtfm.com> <455B6306.2000508@cisco.com> <86irhgcs93.fsf@raman.networkresonance.com> <455E1B76.50104@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78CD439E-BB51-46F3-93D1-A848222E7C12@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Revison of WGLC on draft-ietf-sip-gruu Date: Fri, 17 Nov 2006 23:13:05 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 17, 2006, at 2:28 PM, Paul Kyzivat wrote: > > > Eric Rescorla wrote: > >>>> The problem isn't primarily that they're not opposites, but rather >>>> that they're orthogonal properties and therefore don't divide >>>> the space. Why can't you have a temporary public gruu? >>> To me, "public" was trying to summarize two key properties: >>> >>> 1. relative long lived-ness >>> 2. correlatable to the AOR >>> >>> with that notion of "public", a temporary public gruu isn't >>> sensible. >> Sure, but I don't think that's the connotation it actually has... > > IMO we won't find any terms with names that are acceptably short > and memorable and have precisely the correct connotation for > everybody. > > While the names clearly are intended to have some meaningful > connotation, when you get down to the details it is the formal > definition in the spec that matters. I don't think the current > names are going to cause anybody to make some huge mistake, so I > think they are good enough. > > If there is a decision to change them, then I think we will either > spend a bunch of time just arguing about what name to use, or else > we will pick other names that have other problems, or both. > Personally, I like r-gruu and l-gruu, based on which hemisphere of the brain might choose to use them. Or maybe statgruu and dyngruu, referring not to their functions, but to a couple of engineering classes (statics and dynamics) that pained me almost as much as this conversation. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 18 07:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOq5-0004kJ-Rm; Sat, 18 Nov 2006 06:58:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOq4-0004ix-0b for sip@ietf.org; Sat, 18 Nov 2006 06:58:28 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlOq2-0005YC-Nk for sip@ietf.org; Sat, 18 Nov 2006 06:58:27 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id B52C874033; Sat, 18 Nov 2006 12:58:04 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01039-02-85; Sat, 18 Nov 2006 12:58:04 +0100 (CET) Received: from [192.168.123.17] (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id A1F9F74020; Sat, 18 Nov 2006 12:57:49 +0100 (CET) Message-ID: <455EF52D.3090505@it.su.se> Date: Sat, 18 Nov 2006 12:57:33 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.563 tagged_above=-99 required=7 tests=[AWL=0.102, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: fluffy@cisco.com, sip@ietf.org, "Leis, Peter" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > Hi Peter, > > The primary motivator for outbound is traversal of NATs and firewalls. > There is no technical way that an inbound TCP connection through these > NATs would work. However, outbound allows multiple flows to be > established. A UA could establish both a UDP flow and a TCP flow to > allow for switchover. Can it, in case of an edge proxy being used? An incoming request that has passed the authoritative proxy is already destined for a _specific_ flow between the UA and the edge proxy. This means the authoritative proxy needs information about the transport used for each flow, and use this knowledge when it decides which edge proxy and which flow it should send an incoming request towards. Seems impractical to say the least. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 18 23:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GleXh-0007p0-JB; Sat, 18 Nov 2006 23:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GleXf-0007jC-Ut for sip@ietf.org; Sat, 18 Nov 2006 23:44:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GleXe-0003aA-KT for sip@ietf.org; Sat, 18 Nov 2006 23:44:31 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2006 20:44:30 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAJ4iTKc019900; Sat, 18 Nov 2006 23:44:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAJ4iQYJ017713; Sat, 18 Nov 2006 23:44:26 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 23:44:26 -0500 Received: from [172.28.172.41] ([10.82.217.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 23:44:25 -0500 In-Reply-To: <5C27501E-1377-4484-AD0C-E6732F604E2D@softarmor.com> References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> <5C27501E-1377-4484-AD0C-E6732F604E2D@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EABDD70-CDE8-4FB1-9944-65A6F5B3863B@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] issue with oubound and the used transport protocol Date: Sat, 18 Nov 2006 23:44:29 -0500 To: "Leis, Peter" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Nov 2006 04:44:26.0182 (UTC) FILETIME=[64297660:01C70B95] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2581; t=1163911469; x=1164775469; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20issue=20with=20oubound=20and=20the=20used=20t ransport=20protocol |Sender:=20 |To:=20=22Leis,=20Peter=22=20; bh=xDc+oENliGwhRS1SV8dKFap0IXlNwE8ix295v0nwkT4=; b=heErx3el42PBEE4zfST5Py8UhchU+pTMq7EsV5Wjeg3u10b3MAdbN/gYvkpThXgBEwmScxut flrSFJi5GMoQRH08hxrYmKRZMo5Z+yZWSNKSpUPrGIUF3DIwg1r3GdBP; Authentication-Results: rtp-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Peter - this is a good point. I don't think outbound changes SIP in any way on this. If your UA supports TCP and UDP and your proxy had deployed both, then using TCP or both is a *real good idea*. This is as true in 3261 as it is with outbound. If your UA does not support TCP or your proxy does not allow TCP to be used for whatever reasons - then switching does not work. Again outbound is same as 3261 here. The gist of this is that deprecating UDP is a very separable problem from outbound and that I think outbound is the wrong place to go have this debate. I have no problem pointing out that when doing outbound, if you don't register withy TCP, the proxy can't switch from UDP to TCP. For better or worse, I do expect to see lots of UDP only usage of outbound in the next few years. On Nov 17, 2006, at 10:43 AM, Dean Willis wrote: > > On Nov 17, 2006, at 7:59 AM, Leis, Peter wrote: > >> hi, >> >> after review of draft-ietf-sip-outbound-05 I have the following >> questions related to the used transport protocol >> >> It appears that Outbound-05 does not allow to switch the transport >> protocol over which SIP is used. Outbound-05 says that a User Agent >> terminating SIP request has to be sent to the User Agent over the >> flow >> on which the REGISTER was received. The definition of flow in >> Outbound-05 includes also the transport protocol. Now there seems >> to be >> a problem when the REGISTER was sent over UDP and, at some point >> later, >> a SIP INVITE request is too long to be sent over UDP, so that it >> needs >> to be sent over TCP (see RFC 3261 section 18.1.1). This seems not >> possible with Outbound-05. The switchover from UDP to TCP is a strong >> requirement and in case this is not supported the usability of the >> draft >> seems to be rather restricted. > > A UA that is expecting to engage in this behavior would need to > establish TCP and UDP bindings via outbound registration. > > I suppose one could extend the system to add a management message > that would tell a UA that had registered using UDP to build up a > new registration using TCP, but we don't have anything quite like > this now. There have been some suggestions from the systems > management people that there would be interest in using SIP to tell > a UA to establish a "management connection" on demand, and what > you're suggesting is fairly similar. > > Or we could just deprecate UDP. Folks know where I stand on that > one . . . > > > -- > Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 19 00:29:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlfEC-0006dz-JQ; Sun, 19 Nov 2006 00:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlfEB-0006ds-Ab for sip@ietf.org; Sun, 19 Nov 2006 00:28:27 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlfE9-0007GY-W9 for sip@ietf.org; Sun, 19 Nov 2006 00:28:27 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kAJ5Rv215809; Sat, 18 Nov 2006 21:27:57 -0800 In-Reply-To: <455EF52D.3090505@it.su.se> References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> <455EF52D.3090505@it.su.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03d432b26f3ca4616a7d60b235a322e6@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Sat, 18 Nov 2006 21:28:07 -0800 To: Fredrik Thulin X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Fredrik, I was thinking that the UDP flow would fail and the proxy would try the next flow (which happens to be CP), but I realized that we have no response to convey this semantic. The 430 Flow Failed response code won't work here because the flow hasn't failed, it just can't be used for this transaction. thanks, -rohan On Nov 18, 2006, at 3:57, Fredrik Thulin wrote: > Rohan Mahy wrote: >> Hi Peter, >> The primary motivator for outbound is traversal of NATs and >> firewalls. There is no technical way that an inbound TCP connection >> through these NATs would work. However, outbound allows multiple >> flows to be established. A UA could establish both a UDP flow and a >> TCP flow to allow for switchover. > > Can it, in case of an edge proxy being used? An incoming request that > has passed the authoritative proxy is already destined for a > _specific_ flow between the UA and the edge proxy. > > This means the authoritative proxy needs information about the > transport used for each flow, and use this knowledge when it decides > which edge proxy and which flow it should send an incoming request > towards. Seems impractical to say the least. > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 19 05:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GljXp-0004UB-Ge; Sun, 19 Nov 2006 05:05:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GljXo-0004U6-Qi for sip@ietf.org; Sun, 19 Nov 2006 05:05:00 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GljXl-0007U1-Ba for sip@ietf.org; Sun, 19 Nov 2006 05:05:00 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8Z00B752NW1V@siemenscomms.co.uk> for sip@ietf.org; Sun, 19 Nov 2006 10:04:44 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LHD0VK>; Sun, 19 Nov 2006 10:04:35 +0000 Content-return: allowed Date: Sun, 19 Nov 2006 10:04:28 +0000 From: "Elwell, John" Subject: RE: [Sip] Re: New work: Option-tag for ICE To: Brian Stucker , Jonathan Rosenberg , "Drage, Keith (Keith)" Message-id: <50B1CBA96870A34799A506B2313F26670A6112E8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: 17 November 2006 18:05 > To: Elwell, John; Jonathan Rosenberg; Drage, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > John, > > Ah, I wasn't thinking about 3PCC in my comment. > > If there's a tag in the registered contact for the UA that > the offerless > INVITE is for though, then the INVITE going out could have the option > tag in it (as the B2BUA would know something about the UA it's > initiating 3PCC for). [JRE] I don't think this is a reasonable assumption. The B2BUA is initiating a call from A to B, where A is in its domain, say, but B could be anywhere. It sends an offerless INVITE to A. It is unlikely to know the capabilities of B. Yes, I appreciate that it can also happen the opposite way round, in which case the option tag could work. The point is, there are so many circumstances in which an offerless INVITE can be used that I don't think it is reasonable to assume that the absence of Supported: ice means that ICE is definitely not supported. > > If we allowed the Supported header to be in responses, then you could > even let the option-tag flow across the B2BUA as part of the > 3PCC setup. > As an aside, why on earth do we not allow the Supported header in a > response other than 2xx (looking at 3261)? > > Regards, > Brian > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Friday, November 17, 2006 11:42 AM > > To: Stucker, Brian (RICH1:AR00); Jonathan Rosenberg; Drage, > > Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > > > Brian, > > > > You miss my point. I am not talking about a B2BUA stripping > > an option tag from a received INVITE request before > > forwarding the request. I am talking about a B2BUA > > originating an INVITE request (during a 3PCC make call > > situation). In this case the B2BUA has no grounds on which to > > include the option tag. > > > > John > > > > > -----Original Message----- > > > From: Brian Stucker [mailto:bstucker@nortel.com] > > > Sent: 17 November 2006 15:58 > > > To: Elwell, John; Jonathan Rosenberg; Drage, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Friday, November 17, 2006 2:13 AM > > > > To: Jonathan Rosenberg; Drage, Keith (Keith) > > > > Cc: IETF SIP List > > > > Subject: RE: [Sip] Re: New work: Option-tag for ICE > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > > Sent: 13 November 2006 16:48 > > > > > To: Drage, Keith (Keith) > > > > > Cc: IETF SIP List > > > > > Subject: [Sip] Re: New work: Option-tag for ICE > > > > > > > > > > The semantics for the option tag are the same as for any > > > > other option > > > > > tag - it means that ICE is supported. > > > > > > > > > > ICE is normally signaled through SDP attributes, and there > > > > is no need > > > > > for an option tag for the "normal" call flows. However, > > > we ran into > > > > > some issues with offerless INVITEs. In particular, it would > > > > be really, > > > > > really helpful for a UA to construct an offer in a 18x or > > > > 2xx based on > > > > > knowledge of whether the UA that sent the INVITE supports > > > > ICE. If they > > > > > don't, there is no need to gather candidates in > > > > constructing an offer > > > > > in the response. > > > > [JRE] Of course this doesn't help if the offerless > INVITE request > > > > came from a B2BUA that does not handle SDP/media. The > B2BUA might > > > > not know whether the UA to which the SDP offer will be > > sent supports > > > > ICE or not. So the absence of > > > > Supported: ice would not necessarily be safe grounds > for skipping > > > > ICE stuff. > > > > > > > > John > > > > > > > > > > You could make the same case for any options tag. For > > instance, some > > > B2BUA's strip out the 100rel tag from the supported > header because > > > they want to muck with the early media being generated, and > > don't want > > > the hassle of having to deal with PRACK on one side of the > > call, and > > > not on the other side. > > > > > > Just because there's something in the middle that may strip the > > > options tag doesn't mean that it is of no utility. There's > > really no > > > reason for a B2BUA to strip out the ice option tag given all the > > > backoff logic built into the draft when the other side > > appears to not > > > support ICE. If the B2BUA really didn't want ICE to run, it > > would also > > > be messing with the SDP crossing through it too. So where's > > the harm? > > > > > > Regards, > > > Brian > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From samuelcharil@clubberuk.freeuk.com Sun Nov 19 19:36:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glx8m-0007bx-G8 for sip-archive@lists.ietf.org; Sun, 19 Nov 2006 19:36:04 -0500 Received: from cpe-69-203-200-38.nyc.res.rr.com ([69.203.200.38] helo=hffjoklg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Glx8h-0001lV-BC for sip-archive@lists.ietf.org; Sun, 19 Nov 2006 19:36:00 -0500 Message-ID: <002701c70c35.1779b280.512ac0a8@jemie> Date: Sun, 19 Nov 2006 23:47:37 +0000 From: hatti chev User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: bibby boycie Subject: Good evening Content-Type: multipart/alternative; boundary="---------00000020.01C70C35" X-Spam-Score: 3.2 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. -----------00000020.01C70C35 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit SRRL IS ABOUT TO REACH NEW HIGHS! IMMENSE MOMENTUM IS BUILDING UP! ADD SRRL TO YOUR RADAR ON MON NOV 20! Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB) Symbol: SRRL Price: $.85 5-day Target: $5 Current Market: Bullish OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH! SRRL MAKES STUNNING ANNOUNCEMENT: • Stellar Resources, Ltd. - Company Identifies Development Target THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER! THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA! WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH! -----------00000020.01C70C35 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
SRRL IS ABOUT TO REACH NEW HIGHS!
IMMENSE MOMENTUM IS BUILDING UP!
ADD SRRL TO YOUR RADAR ON MON NOV 20!

Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB)
Symbol: SRRL
Price: $.85
5-day Target: $5
Current Market: Bullish

OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH!

SRRL MAKES STUNNING ANNOUNCEMENT:
• Stellar Resources, Ltd. - Company Identifies Development Target

THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER!
THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA!
WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH!
-----------00000020.01C70C35-- From sip-bounces@ietf.org Sun Nov 19 22:34:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlzqB-0002BV-Jc; Sun, 19 Nov 2006 22:29:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glzq8-0002AS-U7 for sip@ietf.org; Sun, 19 Nov 2006 22:29:01 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glzq7-0007Hq-Oh for sip@ietf.org; Sun, 19 Nov 2006 22:29:00 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2006112003285901100rirgne>; Mon, 20 Nov 2006 03:28:59 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAK3SwFL027277 for ; Sun, 19 Nov 2006 22:28:58 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAK3SwCX027273; Sun, 19 Nov 2006 22:28:58 -0500 Date: Sun, 19 Nov 2006 22:28:58 -0500 Message-Id: <200611200328.kAK3SwCX027273@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437111821048@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [Sip] Re: New work: Option-tag for ICE References: <6FC4416DDE56C44DA0AEE67BC7CA437111821048@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Brian Stucker" As an aside, why on earth do we not allow the Supported header in a response other than 2xx (looking at 3261)? I would assume it's because non-2xx responses are always terminal.. Though the omission of 1xx responses seems to be a mistake. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 01:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2AX-00056q-Dz; Mon, 20 Nov 2006 00:58:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2AV-000552-Ew for sip@ietf.org; Mon, 20 Nov 2006 00:58:11 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm2AL-0000jP-R6 for sip@ietf.org; Mon, 20 Nov 2006 00:58:11 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D846B6F7; Mon, 20 Nov 2006 06:57:50 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 06:57:50 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 06:57:47 +0100 Message-ID: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> In-Reply-To: <002f01c70a6c$be4c0fb0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccKbYCnBZEgqdWJTmSYnU7XZGLpqgB+xoJQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Rohan Mahy" , "Leis, Peter" X-OriginalArrivalTime: 20 Nov 2006 05:57:50.0627 (UTC) FILETIME=[CFD42F30:01C70C68] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >The outbound draft needs to say: "if a UA establishes a flow using an unreliable transport, it MUST also establish one=20 >over a reliable transport" (to support switch over). I think it's enough to have a recommendation. In some cases it may not be possible/feasible to establish a TCP connection - no matter if you use outbound or not. Regards, Christer >Moreover, I would suggest to add "it is RECOMMENDED that the UA establishes a flow using a reliable transport" >=20 > Regards, > Jeroen >=20 > Rohan Mahy wrote: > > Hi Peter, > > > > The primary motivator for outbound is traversal of NATs and=20 > firewalls. > > There is no technical way that an inbound TCP connection=20 > through these=20 > > NATs would work. However, outbound allows multiple flows to be=20 > > established. A UA could establish both a UDP flow and a=20 > TCP flow to=20 > > allow for switchover. > > > > I will point out that the initially the outbound spec only=20 > addressed=20 > > stream-oriented flows. > > > > thanks, > > -rohan > > > > On Nov 17, 2006, at 5:59, Leis, Peter wrote: > >> hi, > >> > >> after review of draft-ietf-sip-outbound-05 I have the following=20 > >> questions related to the used transport protocol > >> > >> It appears that Outbound-05 does not allow to switch the transport=20 > >> protocol over which SIP is used. Outbound-05 says that a=20 > User Agent=20 > >> terminating SIP request has to be sent to the User Agent over the=20 > >> flow on which the REGISTER was received. The definition of flow in > >> Outbound-05 includes also the transport protocol. Now=20 > there seems to=20 > >> be a problem when the REGISTER was sent over UDP and, at=20 > some point=20 > >> later, a SIP INVITE request is too long to be sent over=20 > UDP, so that=20 > >> it needs to be sent over TCP (see RFC 3261 section 18.1.1). This=20 > >> seems not possible with Outbound-05. The switchover from=20 > UDP to TCP=20 > >> is a strong requirement and in case this is not supported the=20 > >> usability of the draft seems to be rather restricted. > >> > >> > >> Peter > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 01:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2Gp-0008QJ-O2; Mon, 20 Nov 2006 01:04:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2Go-0008QA-2w for sip@ietf.org; Mon, 20 Nov 2006 01:04:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm2Gm-0001Ds-JF for sip@ietf.org; Mon, 20 Nov 2006 01:04:42 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AE8215AD; Mon, 20 Nov 2006 07:04:37 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 07:04:37 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 07:04:36 +0100 Message-ID: <7374777208BDC7449D5620EF942325676E73A2@esealmw113.eemea.ericsson.se> In-Reply-To: <6EABDD70-CDE8-4FB1-9944-65A6F5B3863B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] issue with oubound and the used transport protocol Thread-Index: AccLlv4DajV62ZcPSe6oLUMKAnS7JgA0qeNg From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Leis, Peter" X-OriginalArrivalTime: 20 Nov 2006 06:04:37.0403 (UTC) FILETIME=[C24946B0:01C70C69] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: SIP , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Cullen. Regards, Christer=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 19. marraskuuta 2006 6:44 > To: Leis, Peter > Cc: SIP; Rohan Mahy; Dean Willis > Subject: Re: [Sip] issue with oubound and the used transport protocol >=20 >=20 > Peter - this is a good point. >=20 > I don't think outbound changes SIP in any way on this. If=20 > your UA supports TCP and UDP and your proxy had deployed=20 > both, then using TCP or both is a *real good idea*. This is=20 > as true in 3261 as it is with outbound. If your UA does not=20 > support TCP or your proxy does not allow TCP to be used for=20 > whatever reasons - then switching does not work. Again=20 > outbound is same as 3261 here. >=20 > The gist of this is that deprecating UDP is a very separable=20 > problem from outbound and that I think outbound is the wrong=20 > place to go have this debate. >=20 > I have no problem pointing out that when doing outbound, if=20 > you don't register withy TCP, the proxy can't switch from UDP to TCP. >=20 > For better or worse, I do expect to see lots of UDP only=20 > usage of outbound in the next few years. >=20 >=20 > On Nov 17, 2006, at 10:43 AM, Dean Willis wrote: >=20 > > > > On Nov 17, 2006, at 7:59 AM, Leis, Peter wrote: > > > >> hi, > >> > >> after review of draft-ietf-sip-outbound-05 I have the following=20 > >> questions related to the used transport protocol > >> > >> It appears that Outbound-05 does not allow to switch the transport=20 > >> protocol over which SIP is used. Outbound-05 says that a=20 > User Agent=20 > >> terminating SIP request has to be sent to the User Agent over the=20 > >> flow on which the REGISTER was received. The definition of flow in > >> Outbound-05 includes also the transport protocol. Now=20 > there seems to=20 > >> be a problem when the REGISTER was sent over UDP and, at=20 > some point=20 > >> later, a SIP INVITE request is too long to be sent over=20 > UDP, so that=20 > >> it needs to be sent over TCP (see RFC 3261 section 18.1.1). This=20 > >> seems not possible with Outbound-05. The switchover from=20 > UDP to TCP=20 > >> is a strong requirement and in case this is not supported the=20 > >> usability of the draft seems to be rather restricted. > > > > A UA that is expecting to engage in this behavior would need to=20 > > establish TCP and UDP bindings via outbound registration. > > > > I suppose one could extend the system to add a management=20 > message that=20 > > would tell a UA that had registered using UDP to build up a new=20 > > registration using TCP, but we don't have anything quite like this=20 > > now. There have been some suggestions from the systems management=20 > > people that there would be interest in using SIP to tell a UA to=20 > > establish a "management connection" on demand, and what you're=20 > > suggesting is fairly similar. > > > > Or we could just deprecate UDP. Folks know where I stand on=20 > that one .=20 > > . . > > > > > > -- > > Dean >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 02:19:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm3Ou-0000up-JQ; Mon, 20 Nov 2006 02:17:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm3Ot-0000s1-RJ for sip@ietf.org; Mon, 20 Nov 2006 02:17:07 -0500 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm3On-0000Lu-Hu for sip@ietf.org; Mon, 20 Nov 2006 02:17:07 -0500 Received: from Inbox ([84.241.222.31]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9000JNAPJKT540@jes-fe1.zx.nl> for sip@ietf.org; Mon, 20 Nov 2006 08:16:46 +0100 (CET) Date: Mon, 20 Nov 2006 08:16:44 +0100 From: Jeroen Van Bemmel Subject: RE: [Sip] Re: issue with oubound and the used transport protocol To: "Christer Holmberg (JO/LMF)" , Rohan Mahy , "Leis, Peter" Message-id: <0J9000JNBPJMT540@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK, so a SHOULD with explanation then? Jeroen -----Oorspronkelijk bericht ----- Van: "Christer Holmberg (JO/LMF)" Aan: "Jeroen van Bemmel" ; "Rohan Mahy" ; "Leis, Peter" CC: fluffy@cisco.com; "Rohan Mahy" ; sip@ietf.org Verzonden: 20-11-06 06:57 Onderwerp: RE: [Sip] Re: issue with oubound and the used transport protocol Hi,=20 >The outbound draft needs to say: "if a UA establishes a flow using an unreliable transport, it MUST also establish one=20 >over a reliable transport" (to support switch over). I think it's enough to have a recommendation. In some cases it may not be possible/feasible to establish a TCP connection - no matter if you use outbound or not. Regards, Christer >Moreover, I would suggest to add "it is RECOMMENDED that the UA establishes a flow using a reliable transport" >=20 > Regards, > Jeroen >=20 > Rohan Mahy wrote: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 02:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm3wJ-00066P-3p; Mon, 20 Nov 2006 02:51:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm3wH-00066J-UZ for sip@ietf.org; Mon, 20 Nov 2006 02:51:37 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm3wG-0005dO-HR for sip@ietf.org; Mon, 20 Nov 2006 02:51:37 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 59D3B3BE90; Mon, 20 Nov 2006 08:51:21 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17505-02-39; Mon, 20 Nov 2006 08:51:21 +0100 (CET) Received: from [193.11.30.71] (dhcp-wavelan-vo-71.publik.su.se [193.11.30.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 6364B3BE24; Mon, 20 Nov 2006 08:51:11 +0100 (CET) Message-ID: <45615E5C.2050606@it.su.se> Date: Mon, 20 Nov 2006 08:50:52 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] issue with oubound and the used transport protocol References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> <5C27501E-1377-4484-AD0C-E6732F604E2D@softarmor.com> <6EABDD70-CDE8-4FB1-9944-65A6F5B3863B@cisco.com> In-Reply-To: <6EABDD70-CDE8-4FB1-9944-65A6F5B3863B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.648 tagged_above=-99 required=7 tests=[AWL=0.017, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: SIP , Rohan Mahy , "Leis, Peter" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: ... > I don't think outbound changes SIP in any way on this. If your UA > supports TCP and UDP and your proxy had deployed both, then using TCP or > both is a *real good idea*. This is as true in 3261 as it is with > outbound. If your UA does not support TCP or your proxy does not allow > TCP to be used for whatever reasons - then switching does not work. > Again outbound is same as 3261 here. I don't agree with the "or both" part of your recommendation above. As I see it, if your UA and your proxy both support TCP (or TLS) you SHOULD NOT use UDP since that would increase the probability of something failing. Such failures will be fairly hard to diagnose too, and will lead to UAs being written in a way where they retry say a re-INVITE until it succeeds or the user aborts. Also, I don't think that outbound is 100% the same as 3261 in this aspect. Outbound actually prevents (edge) proxies from picking a transport themselves, since requests they receive can/will be targeted at a _specific flow_. > The gist of this is that deprecating UDP is a very separable problem > from outbound and that I think outbound is the wrong place to go have > this debate. I guess some people don't want to have that debate anywhere at all. Is there someone that wouldn't agree that it is easier for a client to get the desired properties of outbound with TLS/TCP than with UDP? The desired properties here is to get through NATs. If there are no one that objects to this, then why would it be so hard to say that a UA that wants these properties MUST (or at least SHOULD) NOT use UDP? This is not the same as deprecating SIP over UDP. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 02:52:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm3xL-0006UZ-6v; Mon, 20 Nov 2006 02:52:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm3xJ-0006UQ-5a for sip@ietf.org; Mon, 20 Nov 2006 02:52:41 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm3xC-0005gq-KP for sip@ietf.org; Mon, 20 Nov 2006 02:52:41 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D60F47A5; Mon, 20 Nov 2006 08:52:31 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 08:52:31 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 08:52:30 +0100 Message-ID: <7374777208BDC7449D5620EF942325676E76D3@esealmw113.eemea.ericsson.se> In-Reply-To: <0J9000JNBPJMT540@jes-fe1.zx.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccMc9dfFZ6ybtLgSN+4xofL4bbXnAABMoPg From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen Van Bemmel" , "Rohan Mahy" , "Leis, Peter" X-OriginalArrivalTime: 20 Nov 2006 07:52:31.0617 (UTC) FILETIME=[D537EF10:01C70C78] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't even think we should have a SHOULD in this case. As Cullen said, I think the it's-better-to-use-TCP-than-UDP is a core SIP issue, and not only related to outbound. But, yes, we can explain the issue. Regards, Christer=20 > -----Original Message----- > From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: 20. marraskuuta 2006 9:17 > To: Christer Holmberg (JO/LMF); Rohan Mahy; Leis, Peter > Cc: fluffy@cisco.com; Rohan Mahy; sip@ietf.org > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > OK, so a SHOULD with explanation then? >=20 > Jeroen >=20 > -----Oorspronkelijk bericht ----- > Van: "Christer Holmberg (JO/LMF)" > Aan: "Jeroen van Bemmel" ; "Rohan Mahy"=20 > ; "Leis, Peter" > CC: fluffy@cisco.com; "Rohan Mahy" ; sip@ietf.org > Verzonden: 20-11-06 06:57 > Onderwerp: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > Hi,=20 >=20 > >The outbound draft needs to say: "if a UA establishes a flow using an > unreliable transport, it MUST also establish one=20 > >over a reliable transport" (to support switch over). >=20 > I think it's enough to have a recommendation. In some cases=20 > it may not be possible/feasible to establish a TCP connection=20 > - no matter if you use outbound or not. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > >Moreover, I would suggest to add "it is RECOMMENDED that the UA > establishes a flow using a reliable transport" > >=20 > > Regards, > > Jeroen > >=20 > > Rohan Mahy wrote: >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 03:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Cf-0003m5-Dg; Mon, 20 Nov 2006 03:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Cd-0003lk-Hc for sip@ietf.org; Mon, 20 Nov 2006 03:08:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm4Cc-0007zb-3b for sip@ietf.org; Mon, 20 Nov 2006 03:08:31 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3BDA34AC; Mon, 20 Nov 2006 09:08:27 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 09:08:26 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 09:08:26 +0100 Message-ID: <7374777208BDC7449D5620EF942325676E7836@esealmw113.eemea.ericsson.se> In-Reply-To: <45615E5C.2050606@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] issue with oubound and the used transport protocol Thread-Index: AccMeTKdntbTC3Y4QSqqMDJwSPy1MAAAOzXw From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , "Cullen Jennings" X-OriginalArrivalTime: 20 Nov 2006 08:08:26.0886 (UTC) FILETIME=[0E9A6A60:01C70C7B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP , Rohan Mahy , "Leis, Peter" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I don't think outbound changes SIP in any way on this. If your UA=20 >>supports TCP and UDP and your proxy had deployed both, then=20 >>using TCP or both is a *real good idea*. This is as true in 3261 as=20 >>it is with outbound. If your UA does not support TCP or your proxy=20 >>does not allow TCP to be used for whatever reasons - then switching does not work. >>Again outbound is same as 3261 here. >=20 >I don't agree with the "or both" part of your recommendation above. >=20 >As I see it, if your UA and your proxy both support TCP (or=20 >TLS) you SHOULD NOT use UDP since that would increase the=20 >probability of something failing. Such failures will be=20 >fairly hard to diagnose too, and will lead to UAs being=20 >written in a way where they retry say a re-INVITE until it=20 >succeeds or the user aborts. >=20 >Also, I don't think that outbound is 100% the same as 3261 in=20 >this aspect. Outbound actually prevents (edge) proxies from=20 >picking a transport themselves, since requests they receive=20 >can/will be targeted at a _specific flow_. The edge proxy can return a error code (whatever the value will be), and the one actually choosing the flow can choose another flow. Then we need to think whether the one choosing the flow knows which flow will be TCP, or if the information needs to be provided in some header/header parameter. >>The gist of this is that deprecating UDP is a very separable problem from outbound and that I think outbound is the wrong place=20 >>to go have his debate. >=20 >I guess some people don't want to have that debate anywhere at all. For SIP/2.0, I think it's too late to have that debate. =20 >Is there someone that wouldn't agree that it is easier for a=20 >client to get the desired properties of outbound with TLS/TCP=20 >than with UDP? The desired properties here is to get through NATs. >=20 >If there are no one that objects to this, then why would it=20 >be so hard to say that a UA that wants these properties MUST=20 >(or at least SHOULD) NOT use UDP? This is not the same as=20 >deprecating SIP over UDP. You can have NATs even if you don't use outbound. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 03:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Zu-00043L-CG; Mon, 20 Nov 2006 03:32:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Zs-00043F-Us for sip@ietf.org; Mon, 20 Nov 2006 03:32:32 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm4Zr-0003Xk-Lm for sip@ietf.org; Mon, 20 Nov 2006 03:32:32 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 141A83BF3E; Mon, 20 Nov 2006 09:32:19 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21854-01-41; Mon, 20 Nov 2006 09:32:18 +0100 (CET) Received: from [193.11.30.71] (dhcp-wavelan-vo-71.publik.su.se [193.11.30.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id BF6853BE3B; Mon, 20 Nov 2006 09:32:17 +0100 (CET) Message-ID: <456167FF.4070006@it.su.se> Date: Mon, 20 Nov 2006 09:31:59 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] issue with oubound and the used transport protocol References: <7374777208BDC7449D5620EF942325676E7836@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325676E7836@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.648 tagged_above=-99 required=7 tests=[AWL=0.017, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Cullen Jennings , SIP , Dean Willis , "Leis, Peter" , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: ... > The edge proxy can return a error code (whatever the value will be), and > the one actually choosing the flow can choose another flow. > > Then we need to think whether the one choosing the flow knows which flow > will be TCP, or if the information needs to be provided in some > header/header parameter. This will be neither simple nor fast, and therefor not good. So let's not go that way. >> Is there someone that wouldn't agree that it is easier for a >> client to get the desired properties of outbound with TLS/TCP >> than with UDP? The desired properties here is to get through NATs. >> >> If there are no one that objects to this, then why would it >> be so hard to say that a UA that wants these properties MUST >> (or at least SHOULD) NOT use UDP? This is not the same as >> deprecating SIP over UDP. > > You can have NATs even if you don't use outbound. So what was your point exactly? Did you object to my statement that UAs that wants to get through NATs would be better off using TLS/TCP? /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 03:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4pO-0002Tb-It; Mon, 20 Nov 2006 03:48:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4pM-0002TI-C8 for sip@ietf.org; Mon, 20 Nov 2006 03:48:32 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm4pF-0005Ml-V1 for sip@ietf.org; Mon, 20 Nov 2006 03:48:32 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A7BCC4F0007; Mon, 20 Nov 2006 09:47:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 09:47:04 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 09:46:59 +0100 Message-ID: <7374777208BDC7449D5620EF942325676E7B33@esealmw113.eemea.ericsson.se> In-Reply-To: <456167FF.4070006@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] issue with oubound and the used transport protocol Thread-Index: AccMfmnEP1S1XLa0QL+pn95jJs5noQAATm0w From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" X-OriginalArrivalTime: 20 Nov 2006 08:47:04.0197 (UTC) FILETIME=[73D40350:01C70C80] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Cullen Jennings , SIP , Dean Willis , "Leis, Peter" , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >>>Is there someone that wouldn't agree that it is easier for a client=20 >>>to get the desired properties of outbound with TLS/TCP=20 >>>than with UDP?=20 >>>The desired properties here is to get through NATs. >>> >>>If there are no one that objects to this, then why would it be so=20 >>>hard to say that a UA that wants these properties MUST (or=20 >>>at least SHOULD) NOT use UDP? This is not the same as deprecating SIP over=20 >>>UDP. >>=20 >>You can have NATs even if you don't use outbound. >=20 >So what was your point exactly? Did you object to my=20 >statement that UAs that wants to get through NATs would be=20 >better off using TLS/TCP? I am not objecting. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 04:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm530-0007TG-89; Mon, 20 Nov 2006 04:02:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm52y-0007T8-Bs for sip@ietf.org; Mon, 20 Nov 2006 04:02:36 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm52x-0006uS-1L for sip@ietf.org; Mon, 20 Nov 2006 04:02:36 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7250CD7F; Mon, 20 Nov 2006 10:02:34 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 10:02:34 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 10:02:33 +0100 Message-ID: <7374777208BDC7449D5620EF942325676E7C67@esealmw113.eemea.ericsson.se> In-Reply-To: <1164011130.7342.9.camel@macbuster.research.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccMfYIrG3niyJTeQfGCSSTRMr5B0wABBlog From: "Christer Holmberg \(JO/LMF\)" To: "Aki Niemi" X-OriginalArrivalTime: 20 Nov 2006 09:02:34.0009 (UTC) FILETIME=[9E0A1090:01C70C82] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>The outbound draft needs to say: "if a UA establishes a=20 >>>flow using an unreliable transport, it MUST also establish one >>>over a reliable transport" (to support switch over). >>=20 >>I think it's enough to have a recommendation. In some cases=20 >>it may not be possible/feasible to establish a TCP connection - no=20 >>matter if you use outbound or not. >=20 >Please enumerate the cases. >=20 >Unless there are concrete cases where TCP simply does not=20 >work, I would strongly recommend we drop UDP from outbound=20 >altogether. Remember, UDP already kind of works in presence=20 >of NAT; this is why we have for instance rport. Outbound is not an alternative to rport. Outbound provides you with keep-alives, and multiple flows (in case one fails), which rport doesn't. rport simply tells you where to send some stuff. >Dropping UDP as a choice in outbound will make the decision=20 >to drop it from SIP a lot easier in the long run. Then again,=20 >keeping it in outbound will all but guarantee it will be=20 >absolutely tedious ripping it out later on. >=20 >Oh, and if we did drop UDP, then the choice of the keepalive=20 >mechanism becomes, well, interesting. ;) It can also become interesting with certain security mechanisms, can't it? I remember, from the good old days of the SIP-versus-H.323 "discussions", PowerPoint slides showing how great SIP is because you can use it with both UDP and TCP.... ;) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 05:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6Xa-0004Rw-6t; Mon, 20 Nov 2006 05:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6XW-0004Pt-SA for sip@ietf.org; Mon, 20 Nov 2006 05:38:15 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm6TO-0003uK-QI for sip@ietf.org; Mon, 20 Nov 2006 05:34:00 -0500 Received: from varshakulkarni ([10.50.28.36]) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CCI89242 (AUTH varshakulkarni) for ; Mon, 20 Nov 2006 16:03:55 +0530 (IST) From: Varsha Kulkarni To: Date: Mon, 20 Nov 2006 16:04:53 +0530 Message-ID: <005501c70c8f$8446af30$241c320a@telxsi.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.2900.2180 X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.456183D7.0080,ss=1,fgs=0, ip=10.50.28.36, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] queiry X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Varsha Kulkarni List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, CANCEL request is sent when response to INVITE message is not received. If this INVITE request is lost and UA may still send a CANCEL request. Is this possible? Can CANCEL request be sent without sending an INVITE message? What is the basic difference between INFO and OPTIONS method? can OPTIONS used for mid-call signalling? Why is ACK request required? Is it just to avoid retransmission of response message. This could be done even by starting the media transmission. How are DTMF digits sent before the session setup? Please reply. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 05:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6aH-0004hY-DA; Mon, 20 Nov 2006 05:41:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6aG-0004h2-JM for sip@ietf.org; Mon, 20 Nov 2006 05:41:04 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm6aF-0005Tx-5d for sip@ietf.org; Mon, 20 Nov 2006 05:41:04 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAK8OJEV012172; Mon, 20 Nov 2006 10:25:48 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 10:25:31 +0200 Received: from [172.21.36.67] ([172.21.36.67]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Nov 2006 10:25:32 +0200 Subject: RE: [Sip] Re: issue with oubound and the used transport protocol From: Aki Niemi To: "ext Christer Holmberg (JO/LMF)" In-Reply-To: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Mon, 20 Nov 2006 08:25:30 +0000 Message-Id: <1164011130.7342.9.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 08:25:32.0140 (UTC) FILETIME=[71B3C2C0:01C70C7D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ma, 2006-11-20 kello 06:57 +0100, ext Christer Holmberg (JO/LMF) kirjoitti: > Hi, > > >The outbound draft needs to say: "if a UA establishes a flow using an > unreliable transport, it MUST also establish one > >over a reliable transport" (to support switch over). > > I think it's enough to have a recommendation. In some cases it may not > be possible/feasible to establish a TCP connection - no matter if you > use outbound or not. Please enumerate the cases. Unless there are concrete cases where TCP simply does not work, I would strongly recommend we drop UDP from outbound altogether. Remember, UDP already kind of works in presence of NAT; this is why we have for instance rport. Dropping UDP as a choice in outbound will make the decision to drop it from SIP a lot easier in the long run. Then again, keeping it in outbound will all but guarantee it will be absolutely tedious ripping it out later on. Oh, and if we did drop UDP, then the choice of the keepalive mechanism becomes, well, interesting. ;) Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 05:53:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6lz-0001to-Bx; Mon, 20 Nov 2006 05:53:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6lx-0001px-QC for sip@ietf.org; Mon, 20 Nov 2006 05:53:09 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm6lw-0007FE-CL for sip@ietf.org; Mon, 20 Nov 2006 05:53:09 -0500 Received: from varshakulkarni ([10.50.28.36]) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CCI91324 (AUTH varshakulkarni) for ; Mon, 20 Nov 2006 16:23:05 +0530 (IST) From: Varsha Kulkarni To: Date: Mon, 20 Nov 2006 16:23:57 +0530 Message-ID: <005601c70c92$2e833de0$241c320a@telxsi.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.2900.2180 X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.45618854.0090,ss=1,fgs=0, ip=10.50.28.36, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] quiery X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Varsha Kulkarni List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, CANCEL request is sent when response to INVITE message is not received. If this INVITE request is lost and UA may still send a CANCEL request. Is this possible? Can CANCEL request be sent without sending an INVITE message? What is the basic difference between INFO and OPTIONS method? can OPTIONS used for mid-call signalling? Why is ACK request required? Is it just to avoid retransmission of response message. This could be done even by starting the media transmission. How are DTMF digits sent before the session setup? Please reply. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 06:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7OO-0003hV-H1; Mon, 20 Nov 2006 06:32:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7ON-0003hM-3U for sip@ietf.org; Mon, 20 Nov 2006 06:32:51 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm7OH-00032j-I4 for sip@ietf.org; Mon, 20 Nov 2006 06:32:51 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kAKBWOsx015797 for ; Mon, 20 Nov 2006 05:32:31 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 05:32:26 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 12:32:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Revison of WGLC on draft-ietf-sip-gruu Date: Mon, 20 Nov 2006 12:32:23 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807F375F@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Revison of WGLC on draft-ietf-sip-gruu Thread-Index: AccF5V6D7ES5V05OSYaedrrus0umywGshDaQ From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 20 Nov 2006 11:32:23.0985 (UTC) FILETIME=[8C7B8A10:01C70C97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A reminder that this document needs to be reviewed and comments made by 27th November. Regards Keith=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 13 November 2006 10:21 > To: IETF SIP List > Subject: [Sip] Revison of WGLC on draft-ietf-sip-gruu >=20 > (As WG chair) >=20 > This is to announce a revised working group last call on=20 > draft-ietf-sip-gruu-11, which may be found at: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-11.txt >=20 > This WGLC will end on Monday 27th November. >=20 > Please mail all comments to the SIP list and to the authors. >=20 > The comments from the previous WGLC may all be found at: >=20 > https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.htm=20 >=20 > Or alternatively >=20 > https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v4.doc >=20 > I would ask all who submitted comments against=20 > draft-ietf-sip-gruu-10 to check the resultion of their=20 > comments and if appropriate remake any comments they consider=20 > were not resolved to their satisfaction. >=20 > Regards >=20 > Keith >=20 >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 08:26:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm980-0001WD-Cx; Mon, 20 Nov 2006 08:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm97y-0001W3-Up for sip@ietf.org; Mon, 20 Nov 2006 08:24:02 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm97w-0002Tn-Fm for sip@ietf.org; Mon, 20 Nov 2006 08:24:02 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAKDNejE013223; Mon, 20 Nov 2006 15:23:46 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 15:23:36 +0200 Received: from [172.21.36.67] ([172.21.36.67]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Nov 2006 15:23:36 +0200 Subject: RE: [Sip] Re: issue with oubound and the used transport protocol From: Aki Niemi To: "ext Christer Holmberg (JO/LMF)" In-Reply-To: <7374777208BDC7449D5620EF942325676E7C67@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF942325676E7C67@esealmw113.eemea.ericsson.se> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Mon, 20 Nov 2006 15:23:35 +0200 Message-Id: <1164029015.7482.23.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 13:23:36.0464 (UTC) FILETIME=[15970900:01C70CA7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ma, 2006-11-20 kello 10:02 +0100, ext Christer Holmberg (JO/LMF) kirjoitti: > >>I think it's enough to have a recommendation. In some cases > >>it may not be possible/feasible to establish a TCP connection - no > >>matter if you use outbound or not. > > > >Please enumerate the cases. > > > >Unless there are concrete cases where TCP simply does not > >work, I would strongly recommend we drop UDP from outbound > >altogether. Remember, UDP already kind of works in presence > >of NAT; this is why we have for instance rport. > > Outbound is not an alternative to rport. Outbound provides you with > keep-alives, and multiple flows (in case one fails), which rport > doesn't. rport simply tells you where to send some stuff. I never said it was a replacement. However, the world is full of deployments that use UDP and work through NAT just fine (kind of); some use rport, some use something else. Clearly, these folks aren't holding out their deployments waiting for outbound to finish. Many (including me) here have said TCP/TLS offers UAs superior ability to traverse NAT compared to UDP. Yet, we insist on keeping UDP around claiming it's needed because TCP doesn't sometimes work in outbound. But unless someone can clearly explain where and how TCP fails to work in a show-stopper manner, such claims are hogwash, and we should just bite the bullet and make sip-outbound TCP-only. > >Dropping UDP as a choice in outbound will make the decision > >to drop it from SIP a lot easier in the long run. Then again, > >keeping it in outbound will all but guarantee it will be > >absolutely tedious ripping it out later on. > > > >Oh, and if we did drop UDP, then the choice of the keepalive > >mechanism becomes, well, interesting. ;) > > It can also become interesting with certain security mechanisms, can't > it? > > I remember, from the good old days of the SIP-versus-H.323 > "discussions", PowerPoint slides showing how great SIP is because you > can use it with both UDP and TCP.... ;) Right. And now RealLife is showing that sometimes when it comes to transports (among other things), having too many options is a Bad Thing. ;-) Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 08:47:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9Ug-0003kh-FI; Mon, 20 Nov 2006 08:47:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9Uf-0003kb-DX for sip@ietf.org; Mon, 20 Nov 2006 08:47:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm9UY-0008A2-VY for sip@ietf.org; Mon, 20 Nov 2006 08:47:29 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 680BA4F0003; Mon, 20 Nov 2006 14:45:45 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 14:45:45 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 14:45:44 +0100 Message-ID: <7374777208BDC7449D5620EF94232567717F7F@esealmw113.eemea.ericsson.se> In-Reply-To: <1164029015.7482.23.camel@macbuster.research.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccMpybZ0aF3rgjtRSWlKUNjvHjhkgAAcxXA From: "Christer Holmberg \(JO/LMF\)" To: "Aki Niemi" X-OriginalArrivalTime: 20 Nov 2006 13:45:45.0199 (UTC) FILETIME=[2D93E7F0:01C70CAA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >>Outbound is not an alternative to rport. Outbound provides you with=20 >>keep-alives, and multiple flows (in case one fails), which rport=20 >>doesn't. rport simply tells you where to send some stuff. >=20 >I never said it was a replacement. However, the world is full=20 >of deployments that use UDP and work through NAT just fine=20 >(kind of); some use rport, some use something else. > >Clearly, these folks aren't holding out their deployments waiting for=20 >outbound to finish. I don't think they have to. They can add outbound in future releases, together with whatever other new fancy SIP extensions... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From adangarrik@eraumts.com.pl Mon Nov 20 08:50:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9XM-0004tR-8J for sip-archive@lists.ietf.org; Mon, 20 Nov 2006 08:50:16 -0500 Received: from [221.196.152.251] (helo=phfoljfbgem) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gm9XF-0000LE-Va for sip-archive@lists.ietf.org; Mon, 20 Nov 2006 08:50:16 -0500 Message-ID: <004301c70ca3.f56b4900.8a7ec0a8@katha> Date: Mon, 20 Nov 2006 13:01:14 +0000 From: rustie hannah User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: teddi dane Subject: Got smart Content-Type: multipart/alternative; boundary="---------00000019.01C70CA3" X-Spam-Score: 0.6 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. -----------00000019.01C70CA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit SRRL IS ABOUT TO REACH NEW HIGHS! IMMENSE MOMENTUM IS BUILDING UP! ADD SRRL TO YOUR RADAR ON MON NOV 20! Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB) Symbol: SRRL Price: $.85 5-day Target: $5 Current Market: Bullish OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH! SRRL MAKES STUNNING ANNOUNCEMENT: • Stellar Resources, Ltd. - Company Identifies Development Target THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER! THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA! WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH! -----------00000019.01C70CA3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
SRRL IS ABOUT TO REACH NEW HIGHS!
IMMENSE MOMENTUM IS BUILDING UP!
ADD SRRL TO YOUR RADAR ON MON NOV 20!

Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB)
Symbol: SRRL
Price: $.85
5-day Target: $5
Current Market: Bullish

OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH!

SRRL MAKES STUNNING ANNOUNCEMENT:
• Stellar Resources, Ltd. - Company Identifies Development Target

THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER!
THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA!
WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH!
-----------00000019.01C70CA3-- From sip-bounces@ietf.org Mon Nov 20 09:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmANA-0006F2-UJ; Mon, 20 Nov 2006 09:43:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAN9-0006Ep-3J for sip@ietf.org; Mon, 20 Nov 2006 09:43:47 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAN5-0004Dh-IM for sip@ietf.org; Mon, 20 Nov 2006 09:43:47 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J9100FBWA8MTV@siemenscomms.co.uk> for sip@ietf.org; Mon, 20 Nov 2006 14:43:34 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LH1NZ7>; Mon, 20 Nov 2006 14:43:26 +0000 Content-return: allowed Date: Mon, 20 Nov 2006 14:43:25 +0000 From: "Elwell, John" Subject: RE: [Sip] comments on connected-identity To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F26670A611A1F@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Thanks for your comments. I have attempted to handle most of them in the post-meeting update of the draft, to appear shortly, but in a few cases I have had to err on the cautious side because it has been through WGLC. The comments missing from below are accepted: > > > This document extends the use of the From header field to > allow it to > > convey "connected identity" information (the identity of the > > connected user) in either direction within the context of > an existingINVITE-initiated dialog. > > Is there a reason this is limited to INVITE-initiated > dialogs? There are > use cases for SUBSCRIBE (though admittedly more corner cases). [JRE] Yes, I saw these more as corner cases, although it wouldn't do any harm to permit its use with SUBSCRIBE-initiated dialogs. As this has been through WGLC I would like some other opinions on whether to add this possibility. > > > The provision of the identity of the responder in a response > > ("response identity") is outside the scope of this document. > > I think its worth two sentences that explains why; I can just imagine > implementors asking why they need to send another reuqest > when they can > just modify the To in the response. [JRE] I propose to add just the following: "Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS except in cases where the UA is connected to its proxy by TLS and has already been authenticated. Providing identity in a separate request allows normal authentication techniques." Is this sufficient? > > > The Identity header field is inserted by a suitable Authentication > > Service on the path of the mid-dialog request, typically at a proxy > > that record routes and is able to authenticate the UAC. > > "typically" isn't strong enough; indeed there is a > requirement that the > proxy providing the authtnication service has to record-route. Suggest > removing "typically". [JRE]The point is, it doesn't have to be at a proxy - the UAC itself could provide this service, particularly if it is a gateway. How about "Unless provided at the UAC, the Authentication Service must be at a proxy that record routes and is able to authenticate the UAC"? > > > It is assumed that deployed > > proxies will already be able to tolerate a change of > URI, since this > > has been expected for a considerable time. To cater for > any UAs that > > are not able to tolerate a change of URI, a new option tag "from- > > change" is introduced for providing a positive > indication of support > > in the Supported header field. > > These two sentences are somewhat contradictory. The first > says that its > been long enough that this is not a problem anymore for > proxies. If so, > why is it a problem for UAs which require an option tag? > > I'm curious if we have evidence of any deployed UA at this point that > would break by a change in URI. > > I'm not objecting to the option tag; I just want to make sure > we really > have a need for it. [JRE] This has been in here for some time. I think there was a feeling that the population of dialog stateful proxies will be much smaller than the population of UAs, and also that proxies would perhaps be more likely to be kept up to date. Perhaps that is a wild assumption, but at the time people seemed to want to be more cautious where UAs were concerned. Also the option tag has the useful additional property that it advises a proxy to record route (if not doing so anyway) so that it can deploy an Authentication Service on mid-dialog requests. > > > fter a full dialog has > > been formed (after sending a 2xx provisional response the INVITE > > request), if the "from-change" option tag has been received in a > > Supported header field and an UPDATE request has not already been > > sent on the early dialog, the UA MUST issue an UPDATE > request on the > > same dialog. In either case the UPDATE request MUST contain the > > callee's (or potential callee's) identity in the URI of the From > > header field (or an anonymous identity if anonymity is required). > > I find the "MUST send UPDATE" questionable here. I reserve MUST for > things which break if you don't do them. Clearly, nothing > breaks here if > you don't do this. So I don't think you can do more than SHOULD here. [JRE] An older version did indeed have "SHOULD", but was changed. This is possibly the most essential requirement in the whole spec. What is the point of claiming support for this spec if you don't send an UPDATE request at least in this situation? > > > A proxy that is able to provide an Authentication Service or a > > Verifier for mid-dialog requests MUST record route if Supported: > > from-change is indicated in the dialog forming request. > > I think this rule is really just for authentication services. If the > verifier is in the UA clearly it doesn't need to record-route. [JRE] I tend to agree. There could be a verifier at a proxy, and that proxy is free to record route if it wishes, but I guess we don't need to prescribe that here. So agreed. > > > > 5.2. Sending revised connected identity during a call > > > > In this example a call is established between Alice and > Bob, where > > Bob (not shown) lies behind a B2BUA. Bob's identity is > conveyed by > > an UPDATE request. Then call transfer occurs in the > B2BUA, such that > > Alice becomes connected to Carol (also not shown), and a > re-INVITE > > request is issued allowing the session to be > renegotiated. The B2BUA > > provides the Authentication Service and thus generates > the Identity > > header field in the re-INVITE request to provide > authentication of > > I don't want to encourage b2bua and this form of transfer, so > I'd prefer > that this section be recast as using a pstn gateway. [JRE] This is just an example of what occurs in practice, this being one of the use cases that connected-identity can solve. I will make it clear that the B2BUA is performing 3PCC techniques according to RFC 3725 and cite click-to-dial as an example application. > > > A.2. Existing methods for providing authenticated identity > information > > This appendix doesn't really add much value. I'd suggest removing it. [JRE] I have no objection - it is largely historic, which is why it was relegated to an appendix. If anyone objects to its removal, please shout. > > If anything, the main question folks will have is why not just use > P-A-ID in the 18x or 2xx. As you may know despite RFC 3325 rules that > say this is not allowed, IMS has gone ahead and specified that anyway > for connected identity. [JRE] True, although it shouldn't be used unless there is a means of authenticating the responder (e.g., based on TLS), so it has limitations in theory, even if these limitations are ignored in practice. In fact I think RFC 3325 should be updated to clarify this (i.e. allow PAI in a response in appropriate circumstances). Likewise PAI can be used in a mid-dialog request to indicate a change of identity. But PAI is asserted identity and relies on transitive trust, whereas the objective of connected-identity is to provide an authenticated identity based on RFC 4474. I will add some text at the end of the Introducation section to say why response identity is inappropriate. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 09:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAWg-0008GB-W4; Mon, 20 Nov 2006 09:53:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAWe-0008G5-Sj for sip@ietf.org; Mon, 20 Nov 2006 09:53:36 -0500 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAWd-00054g-7W for sip@ietf.org; Mon, 20 Nov 2006 09:53:36 -0500 Received: by tutpro.com (Postfix, from userid 1001) id 479851ECB82; Mon, 20 Nov 2006 16:53:34 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on lohi.tutpro.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.4 Received: from rautu (unknown [202.3.217.1]) by tutpro.com (Postfix) with ESMTP id E62CB1EC65E; Mon, 20 Nov 2006 16:53:25 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 20111F0129; Mon, 20 Nov 2006 16:51:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17761.49403.63238.199823@rautu.test.fi> Date: Mon, 20 Nov 2006 16:51:39 +0200 From: Juha Heinanen To: "Christer Holmberg \(JO/LMF\)" Subject: RE: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <7374777208BDC7449D5620EF94232567717F7F@esealmw113.eemea.ericsson.se> References: <1164029015.7482.23.camel@macbuster.research.nokia.com> <7374777208BDC7449D5620EF94232567717F7F@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg \(JO/LMF\) writes: > I don't think they have to. They can add outbound in future releases, > together with whatever other new fancy SIP extensions... provided that outbound provides any value add to what we currently already have implemented and is deployable, i.e., there is a standardized dhcp-free discovery mechanism (like the one that jonathan proposed). on another topic, i read jonathan's ice slides and while it provides a little bit more than what we currently have (no need for relay in some scenarios), its complexity was overwhelming and would thus not warrant implementing. -- 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 sip-bounces@ietf.org Mon Nov 20 11:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBYE-0000O0-Jq; Mon, 20 Nov 2006 10:59:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBYD-0000Nk-Ko for sip@ietf.org; Mon, 20 Nov 2006 10:59:17 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBYB-0002Yz-2B for sip@ietf.org; Mon, 20 Nov 2006 10:59:17 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kAKFo9219673; Mon, 20 Nov 2006 07:50:09 -0800 In-Reply-To: <1164011130.7342.9.camel@macbuster.research.nokia.com> References: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> <1164011130.7342.9.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 07:50:19 -0800 To: Aki Niemi X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" , "ext Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Folks, I'd really like to finish outbound. Up until a few days ago, I had incorporated all the comments I'd received except for some style comments I was reviewing from Keith. The problem I see is that we have two separate communities using the outbound draft: 1) folks that want to get through NATs and Firewalls in the public Internet at large - they want to use TCP and TLS with double CRLF for keepalives. One "flow" is always one connection. The milestone for this would read "Make TCP and TLS work in the Internet". 2) folks that want UDP to work through specific NATs even if the edge proxy, NAT, or interface hiccups - some of these folks want to treat multiple IPsec SAs so the definition of "flow" becomes terribly fuzzy to everyone else, and they need to use STUN keepalives. I would like to use this opportunity to point out that if we said "out of scope for now" to outbound over UDP then we would already be done now and there would already be multiple implementations, including one that I started for the repro open source proxy. We would have sidestepped the fuzzy "flow" terminology and all the endless debates about STUN keepalive usage and discovery, since double CRLF is fully backwards compatible with even RFC 2543 implementations. I am bringing this up on the list because I hope the WG can look back on this and not make the mistake of snowballing complexity to preserve UDP parity again in the future. At this point, I believe that these decisions are water under the bridge. I would like to explore ways forward: FASTEST (hold nose and swallow): Normatively RECOMMEND using congestion-safe transports for outbound. Point out that if you only use UDP flows you can't switch over to TCP, and that using a UDP flow when you have a perfectly good TCP flow is complete silliness. I'll point out that TCP has been mandatory to implement in both UAs and proxies for 4 years. CLEANEST (the 2 more years! approach): Split outbound up so that we have at least three drafts: a) an update to Path that uses a reg-id to store multiple bindings/paths back to a UA regardless of transport. this is useful in the multiple radio interface use case for example even if there are no NATs. b) a STUN keep-alive draft - with or without discovery. I'm not writing it--I think it is a terrible idea. c) outbound *connections* draft for TCP and TLS over TCP only. (If you want outbound for SCTP you can write your own damn draft). d) possibly a SIP over UDP NAT traversal draft. Again, I have no interest in working on a draft with this kind of draft. If you think you have a clever/better proposal than one of these, please send me private mail or phone me. Please send comments to the list or directly to me. If you support one of these two approaches, please put FASTEST or CLEANEST in the first line of the message. thanks, -rohan On Nov 20, 2006, at 0:25, Aki Niemi wrote: > ma, 2006-11-20 kello 06:57 +0100, ext Christer Holmberg (JO/LMF) > kirjoitti: >> Hi, >> >>> The outbound draft needs to say: "if a UA establishes a flow using an >> unreliable transport, it MUST also establish one >>> over a reliable transport" (to support switch over). >> >> I think it's enough to have a recommendation. In some cases it may not >> be possible/feasible to establish a TCP connection - no matter if you >> use outbound or not. > > Please enumerate the cases. > > Unless there are concrete cases where TCP simply does not work, I would > strongly recommend we drop UDP from outbound altogether. Remember, UDP > already kind of works in presence of NAT; this is why we have for > instance rport. > > Dropping UDP as a choice in outbound will make the decision to drop it > from SIP a lot easier in the long run. Then again, keeping it in > outbound will all but guarantee it will be absolutely tedious ripping > it > out later on. > > Oh, and if we did drop UDP, then the choice of the keepalive mechanism > becomes, well, interesting. ;) > > Cheers, > Aki > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 12:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCaG-0006Nq-ED; Mon, 20 Nov 2006 12:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCaE-0006Nj-VS for sip@ietf.org; Mon, 20 Nov 2006 12:05:26 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCaC-0007JF-K1 for sip@ietf.org; Mon, 20 Nov 2006 12:05:26 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 2B2F16C018; Mon, 20 Nov 2006 12:05:02 -0500 (EST) Subject: RE: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: "Drage, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 20 Nov 2006 12:05:11 -0500 Message-Id: <1164042311.2868.14.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Cullen Jennings , IETF SIP List , "Vijay K. Gurbani" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-11-13 at 11:20 +0100, Drage, Keith (Keith) wrote: > Question repeat, as it does not seem to have been answered. > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 04 October 2006 19:46 > > To: Cullen Jennings; Dean Willis > > Cc: IETF SIP List; Vijay K. Gurbani > > Subject: RE: [Sip] I-D on handling large UDP responses > > > > Can you tell us what you agreed on. The proceedings seem to > > have missed it, and I don't remember it appearing on the list. I am not at all sure that we agreed on anything with respect to this. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 12:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCYc-0004Wy-8Q; Mon, 20 Nov 2006 12:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCYa-0004Uo-5Z for sip@ietf.org; Mon, 20 Nov 2006 12:03:44 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCYW-0007BT-G5 for sip@ietf.org; Mon, 20 Nov 2006 12:03:44 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAKH36k16106; Mon, 20 Nov 2006 12:03:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Mon, 20 Nov 2006 11:02:58 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711188581C@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A6112E8@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: New work: Option-tag for ICE Thread-Index: AccLwiBoABNls3jFRrquHdHjOhHCwwBA2RTQ From: "Brian Stucker" To: "Elwell, John" , "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > If there's a tag in the registered contact for the UA that the=20 > > offerless INVITE is for though, then the INVITE going out=20 > could have=20 > > the option tag in it (as the B2BUA would know something=20 > about the UA=20 > > it's initiating 3PCC for). > [JRE] I don't think this is a reasonable assumption. The=20 > B2BUA is initiating a call from A to B, where A is in its=20 > domain, say, but B could be anywhere. > It sends an offerless INVITE to A. It is unlikely to know the=20 > capabilities of B. > Yes, I appreciate that it can also happen the opposite way=20 > round, in which case the option tag could work. The point is,=20 > there are so many circumstances in which an offerless INVITE=20 > can be used that I don't think it is reasonable to assume=20 > that the absence of Supported: ice means that ICE is=20 > definitely not supported. True. But it would be nice to be able to optimize the 'opposite way around' though. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 12:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCaG-0006Nq-ED; Mon, 20 Nov 2006 12:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCaE-0006Nj-VS for sip@ietf.org; Mon, 20 Nov 2006 12:05:26 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCaC-0007JF-K1 for sip@ietf.org; Mon, 20 Nov 2006 12:05:26 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 2B2F16C018; Mon, 20 Nov 2006 12:05:02 -0500 (EST) Subject: RE: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: "Drage, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 20 Nov 2006 12:05:11 -0500 Message-Id: <1164042311.2868.14.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Cullen Jennings , IETF SIP List , "Vijay K. Gurbani" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-11-13 at 11:20 +0100, Drage, Keith (Keith) wrote: > Question repeat, as it does not seem to have been answered. > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 04 October 2006 19:46 > > To: Cullen Jennings; Dean Willis > > Cc: IETF SIP List; Vijay K. Gurbani > > Subject: RE: [Sip] I-D on handling large UDP responses > > > > Can you tell us what you agreed on. The proceedings seem to > > have missed it, and I don't remember it appearing on the list. I am not at all sure that we agreed on anything with respect to this. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 12:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCYc-0004Wy-8Q; Mon, 20 Nov 2006 12:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCYa-0004Uo-5Z for sip@ietf.org; Mon, 20 Nov 2006 12:03:44 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCYW-0007BT-G5 for sip@ietf.org; Mon, 20 Nov 2006 12:03:44 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAKH36k16106; Mon, 20 Nov 2006 12:03:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: New work: Option-tag for ICE Date: Mon, 20 Nov 2006 11:02:58 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711188581C@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A6112E8@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: New work: Option-tag for ICE Thread-Index: AccLwiBoABNls3jFRrquHdHjOhHCwwBA2RTQ From: "Brian Stucker" To: "Elwell, John" , "Jonathan Rosenberg" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > If there's a tag in the registered contact for the UA that the=20 > > offerless INVITE is for though, then the INVITE going out=20 > could have=20 > > the option tag in it (as the B2BUA would know something=20 > about the UA=20 > > it's initiating 3PCC for). > [JRE] I don't think this is a reasonable assumption. The=20 > B2BUA is initiating a call from A to B, where A is in its=20 > domain, say, but B could be anywhere. > It sends an offerless INVITE to A. It is unlikely to know the=20 > capabilities of B. > Yes, I appreciate that it can also happen the opposite way=20 > round, in which case the option tag could work. The point is,=20 > there are so many circumstances in which an offerless INVITE=20 > can be used that I don't think it is reasonable to assume=20 > that the absence of Supported: ice means that ICE is=20 > definitely not supported. True. But it would be nice to be able to optimize the 'opposite way around' though. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 14:26:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmElj-0007cv-4g; Mon, 20 Nov 2006 14:25:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmElh-0007NS-Mw for sip@ietf.org; Mon, 20 Nov 2006 14:25:25 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmEhB-0004rO-AN for sip@ietf.org; Mon, 20 Nov 2006 14:20:46 -0500 Received: (from apache@localhost) by figas.ekabal.com (8.11.6/8.11.6) id kAKJKe625352; Mon, 20 Nov 2006 11:20:41 -0800 From: Rohan Mahy X-Authentication-Warning: figas.ekabal.com: apache set sender to rohan@localhost using -f Received: from 12.151.41.2 (SquirrelMail authenticated user rohan); by figas.ekabal.com with HTTP; Mon, 20 Nov 2006 11:20:40 -0800 (PST) Message-ID: <15201.12.151.41.2.1164050440.squirrel@12.151.41.2> Date: Mon, 20 Nov 2006 11:20:40 -0800 (PST) To: sip@ietf.org User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by figas.ekabal.com id kAKJKe625352 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Rohan Mahy Subject: [Sip] outbound open issues from IETF 67 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Folks, I've incorporated all the changes we agreed to at IETF67. For those who have not seen them yet, please consult the slides available here: http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf In addition, I have proposed text for Issues D&E (see below). In summary, we agreed from the meeting: - Consensus to use 430 response - Consensus to keep the "stable flow timer" Bug A: No objection to fixing this bug Issue B: consensus to only require 1st hop and registrar to participate Issue C: consensus for No Action Issue D: did not discuss, proposal mentioned below Issue E: did not discuss, proposal mentioned below Issue F: consensus for No Action Issue 3G: rough consensus to Accept action 2 (Bug A): Provided mention of the 'rport' parameter. (Issue 3G): Relaxed flow-token language slightly. Instead of flow-token saving specific UDP address/port tuples over which the request arrived, make language fuzzy to save token which points to a =91logical flow=92 th= at is known to deliver data to that specific UA instance. (Issue B): Changed registrar verification so that only first-hop proxy an= d the registrar need to support outbound. Other intermediaries in between do not any more. (Issues D&E): Proposal text: The UAC can situationally decide whether to request outbound behavior by including or omitting the 'reg-id' parameter. For example, imagine the outbound-proxy-set contains two proxies in different domains, EP1 and EP2. If an outbound-style registration succeeded for a flow through EP1, the UA might decide to include 'outbound' in its option-tag when registering with EP2, in order to insure consistency. Similarly, if the registration through EP1 did not support outbound, the UA might decide to omit the 'reg-id' parameter when registering with EP2. I believe the proposed text for D&E is sufficient and should be fairly non-controversial. If anyone has any objections, please speak up ASAP (and *send text* ;-). thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 15:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFOw-0007iG-I7; Mon, 20 Nov 2006 15:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFOv-0007i9-5z for sip@ietf.org; Mon, 20 Nov 2006 15:05:57 -0500 Received: from mx1-1.spamtrap.magma.ca ([209.217.78.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFOt-0003Fp-UK for sip@ietf.org; Mon, 20 Nov 2006 15:05:57 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx1-1.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAKK5sTp022244 for ; Mon, 20 Nov 2006 15:05:54 -0500 Received: from [192.168.1.137] ([216.13.42.66]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id kAKK5roY011918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Nov 2006 15:05:55 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) References: <10912104-8C43-479F-BE6A-8EC2BD7C414E@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6262CA6D-BECA-465D-91F0-3AA955AD5F08@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 20 Nov 2006 15:06:05 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] Fwd: Looking for core reviewers for the ICE-related specifications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [Copying the SIP list on this, even though I expect that most people interested in these documents will have gotten the message via either the BEHAVE or MMUSIC lists.] - Philip Begin forwarded message: > From: Philip Matthews > Date: November 20, 2006 13:41:14 EST (CA) > To: behave@ietf.org, IETF MMUSIC WG > Subject: Looking for core reviewers for the ICE-related specifications > > Folks: > > There is a major effort on right now to get all the ICE-related > documents > to RFC status. We are planning to issue WGLCs for most of these > documents > over the next few weeks, with the hope of getting them all > submitted to > the IESG by mid-January. > > There are 6 document which we are classifying as ICE-related: > 1. draft-ietf-behave-3489bis (STUN) > 2. draft-ietf-behave-turn (TURN) (depends on 1) > 3. draft-ietf-mmusic-ice (ICE) (depends on 1 and > 2 and 5) > 4. draft-ietf-mmusic-ice-passive?(ICE-PASSIVE - new document) > (depends on 3) > 5. draft-ietf-sip-ice-option-tag (ICE-OPTION-TAG - new > document) (depends on 3) > 6. draft-ietf-mmusic-ice-tcp (ICE-TCP) (depends on 3) > > As you may be aware, STUN is currently in WGLC, and the other > documents > will enter WGLC shortly in their respective working groups. > > I am currently looking for people who are willing to be on what I > am calling > the "core review team" -- that is, people willing to review all 6 > documents. > These people would comment not only on the individual documents, but > also on their interrelationships. > > Right now, the core review team consists of the following people: > Bruce Lowecamp > Derek MacDonald > Rohan Mahy > Philip Matthews > Dan Wing > > If you are interested in being on this team, or would like more > information, > please let me know. > > - Philip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 16:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGpO-0006lq-3D; Mon, 20 Nov 2006 16:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGpM-0006lk-8W for sip@ietf.org; Mon, 20 Nov 2006 16:37:20 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmGpJ-0006sO-Vx for sip@ietf.org; Mon, 20 Nov 2006 16:37:20 -0500 Received: (qmail 1536 invoked by uid 0); 20 Nov 2006 21:38:25 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Nov 2006 21:38:25 -0000 Message-ID: <006a01c70cec$08f30d30$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" References: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> <1164011130.7342.9.camel@macbuster.research.nokia.com> <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 20 Nov 2006 22:37:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, Minor issue for outbound-05: section 3.1 (and the references) refers to STUN as "Simple Traversal of UDP through NATs". It's now "Simple Traversal Underneath Network Address Translators" (in draft-ietf-behave-rfc3489bis-05.txt) Not that "underneath" makes much sense here (to me), but I guess they wanted backwards compatibility for the acronym while including other transports Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 20 19:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJkE-0008At-W3; Mon, 20 Nov 2006 19:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJkD-0008Ac-Vy for sip@ietf.org; Mon, 20 Nov 2006 19:44:13 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJkC-0007qD-MH for sip@ietf.org; Mon, 20 Nov 2006 19:44:13 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1222634ugd for ; Mon, 20 Nov 2006 16:44:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E4ApmNnQos4ENQAsYIkWoCx6xAafo4zDs9bFXr57nUeSLsy7GyapLJs//b61X5MKG+VrKc+YA5jMIR0DPSgCeA68s1MssyUtbXmsbFzVnCu7v6Sv7EQsGzNdVmXA7/sd/luSwfZTMtsWJ6ylbbNZersoVZP7wYW7ei9EWeEypwI= Received: by 10.78.142.14 with SMTP id p14mr5724774hud.1164069851029; Mon, 20 Nov 2006 16:44:11 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 20 Nov 2006 16:44:10 -0800 (PST) Message-ID: <953beacc0611201644q56c451c4i2b46d25c91728d7f@mail.gmail.com> Date: Mon, 20 Nov 2006 16:44:10 -0800 From: "Rohan Mahy" To: "Jeroen van Bemmel" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <006a01c70cec$08f30d30$0601a8c0@BEMBUSTER> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> <1164011130.7342.9.camel@macbuster.research.nokia.com> <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> <006a01c70cec$08f30d30$0601a8c0@BEMBUSTER> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, Its already fixed in my working copy. many thanks, -rohan On 11/20/06, Jeroen van Bemmel wrote: > Rohan, > > Minor issue for outbound-05: section 3.1 (and the references) refers to STUN > as "Simple Traversal of UDP through NATs". It's now "Simple Traversal > Underneath Network Address Translators" (in > draft-ietf-behave-rfc3489bis-05.txt) > > Not that "underneath" makes much sense here (to me), but I guess they wanted > backwards compatibility for the acronym while including other transports > > Regards, > Jeroen > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 01:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmOhk-00034p-EX; Tue, 21 Nov 2006 01:02:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmOhi-00033y-Ah for sip@ietf.org; Tue, 21 Nov 2006 01:01:58 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmOhg-0005zX-Ql for sip@ietf.org; Tue, 21 Nov 2006 01:01:58 -0500 Received: from varshakulkarni ([10.50.28.36]) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CCJ63335 (AUTH varshakulkarni) for ; Tue, 21 Nov 2006 11:31:47 +0530 (IST) From: Varsha Kulkarni To: Date: Tue, 21 Nov 2006 11:32:44 +0530 Message-ID: <002d01c70d32$aa4e90f0$241c320a@telxsi.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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090207.4562958C.007A,ss=1,fgs=0, ip=10.50.28.36, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sip] INFO call flow X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Varsha Kulkarni List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, Please explain the call flow given in 3.3.1 of Internet Draft by Steve Donovan draft-ietf-sip-info-method-00.txt MCI Worldcom October 1999. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 02:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQ4z-0004qU-1o; Tue, 21 Nov 2006 02:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQ4x-0004oC-Fc for sip@ietf.org; Tue, 21 Nov 2006 02:30:03 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmQ4v-0002V6-TH for sip@ietf.org; Tue, 21 Nov 2006 02:30:03 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id kAL7TkB4030249; Tue, 21 Nov 2006 08:29:47 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAL7TjmX009573; Tue, 21 Nov 2006 08:29:45 +0100 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 08:29:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 21 Nov 2006 08:29:44 +0100 Message-ID: <784A66466728424D93027C59B6478B9E0101E391@MCHP7I5A.ww002.siemens.net> In-Reply-To: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccMvMsrbIFR6ihATn+GnFmgHOZaIAAgNSMQ From: "Leis, Peter" To: "Rohan Mahy" X-OriginalArrivalTime: 21 Nov 2006 07:29:45.0311 (UTC) FILETIME=[D13FEEF0:01C70D3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: fluffy@cisco.com, sip@ietf.org, "ext Christer Holmberg \(JO/LMF\)" , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org CLEANEST Rohan,=20 thanks for presenting the alternatives so clearly. I support CLEANEST, = as this allows people to use the "OUTBOUND techniques" as appropriate = for their environment. Peter=20 > -----Urspr=FCngliche Nachricht----- > Von: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Gesendet: Montag, 20. November 2006 16:50 > An: Aki Niemi > Cc: Jeroen van Bemmel; Leis, Peter; fluffy@cisco.com; Rohan=20 > Mahy; sip@ietf.org; ext Christer Holmberg (JO/LMF) > Betreff: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Hi Folks, >=20 > I'd really like to finish outbound. Up until a few days ago, I had=20 > incorporated all the comments I'd received except for some style=20 > comments I was reviewing from Keith. >=20 > The problem I see is that we have two separate communities using the=20 > outbound draft: >=20 > 1) folks that want to get through NATs and Firewalls in the public=20 > Internet at large - they want to use TCP and TLS with double CRLF for=20 > keepalives. One "flow" is always one connection. The milestone for=20 > this would read "Make TCP and TLS work in the Internet". >=20 > 2) folks that want UDP to work through specific NATs even if the edge=20 > proxy, NAT, or interface hiccups - some of these folks want to treat=20 > multiple IPsec SAs so the definition of "flow" becomes terribly fuzzy=20 > to everyone else, and they need to use STUN keepalives. >=20 > > I would like to use this opportunity to point out that if we=20 > said "out=20 > of scope for now" to outbound over UDP then we would already be done=20 > now and there would already be multiple implementations,=20 > including one=20 > that I started for the repro open source proxy. We would have=20 > sidestepped the fuzzy "flow" terminology and all the endless debates=20 > about STUN keepalive usage and discovery, since double CRLF is fully=20 > backwards compatible with even RFC 2543 implementations. I=20 > am bringing=20 > this up on the list because I hope the WG can look back on=20 > this and not=20 > make the mistake of snowballing complexity to preserve UDP=20 > parity again=20 > in the future. > >=20 > At this point, I believe that these decisions are water under the=20 > bridge. I would like to explore ways forward: >=20 > FASTEST (hold nose and swallow): > Normatively RECOMMEND using congestion-safe transports for outbound. =20 > Point out that if you only use UDP flows you can't switch=20 > over to TCP,=20 > and that using a UDP flow when you have a perfectly good TCP flow is=20 > complete silliness. I'll point out that TCP has been mandatory to=20 > implement in both UAs and proxies for 4 years. >=20 > CLEANEST (the 2 more years! approach): > Split outbound up so that we have at least three drafts: > a) an update to Path that uses a reg-id to store multiple=20 > bindings/paths back to a UA regardless of transport. this is=20 > useful in=20 > the multiple radio interface use case for example even if=20 > there are no=20 > NATs. > b) a STUN keep-alive draft - with or without discovery. I'm not=20 > writing it--I think it is a terrible idea. > c) outbound *connections* draft for TCP and TLS over TCP=20 > only. (If you=20 > want outbound for SCTP you can write your own damn draft). > d) possibly a SIP over UDP NAT traversal draft. Again, I have no=20 > interest in working on a draft with this kind of draft. >=20 > If you think you have a clever/better proposal than one of these,=20 > please send me private mail or phone me. >=20 > Please send comments to the list or directly to me. If you=20 > support one=20 > of these two approaches, please put FASTEST or CLEANEST in the first=20 > line of the message. >=20 > thanks, > -rohan >=20 >=20 > On Nov 20, 2006, at 0:25, Aki Niemi wrote: > > ma, 2006-11-20 kello 06:57 +0100, ext Christer Holmberg (JO/LMF) > > kirjoitti: > >> Hi, > >> > >>> The outbound draft needs to say: "if a UA establishes a=20 > flow using an > >> unreliable transport, it MUST also establish one > >>> over a reliable transport" (to support switch over). > >> > >> I think it's enough to have a recommendation. In some=20 > cases it may not > >> be possible/feasible to establish a TCP connection - no=20 > matter if you > >> use outbound or not. > > > > Please enumerate the cases. > > > > Unless there are concrete cases where TCP simply does not=20 > work, I would > > strongly recommend we drop UDP from outbound altogether.=20 > Remember, UDP > > already kind of works in presence of NAT; this is why we have for > > instance rport. > > > > Dropping UDP as a choice in outbound will make the decision=20 > to drop it > > from SIP a lot easier in the long run. Then again, keeping it in > > outbound will all but guarantee it will be absolutely=20 > tedious ripping=20 > > it > > out later on. > > > > Oh, and if we did drop UDP, then the choice of the=20 > keepalive mechanism > > becomes, well, interesting. ;) > > > > Cheers, > > Aki > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 02:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQMB-0003iW-T0; Tue, 21 Nov 2006 02:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQMA-0003hq-QW for sip@ietf.org; Tue, 21 Nov 2006 02:47:50 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmQM9-0004Ov-7U for sip@ietf.org; Tue, 21 Nov 2006 02:47:50 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAL7kle1031153; Tue, 21 Nov 2006 09:47:27 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 09:47:02 +0200 Received: from 4FIL15472 ([172.17.203.129]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Nov 2006 09:47:01 +0200 From: "Aki Niemi" To: "'ext Rohan Mahy'" Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 21 Nov 2006 09:47:04 +0200 Message-ID: <000001c70d41$3cd0f130$ac98b70a@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AccMvc66N0PJb6rxTT2bgZqth8JNYwAgywnA X-OriginalArrivalTime: 21 Nov 2006 07:47:01.0566 (UTC) FILETIME=[3AE7E5E0:01C70D41] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: fluffy@cisco.com, sip@ietf.org, "'Leis, Peter'" , "'ext Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org CLEANEST (But I sincerely hope it won't be another two years ;) Cheers, Aki >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan@ekabal.com] >Sent: 20 November, 2006 17:50 >To: Aki Niemi >Cc: fluffy@cisco.com; Rohan Mahy; sip@ietf.org; Leis,Peter; >ext Christer Holmberg (JO/LMF) >Subject: Re: [Sip] Re: issue with oubound and the used >transport protocol > >Hi Folks, > >I'd really like to finish outbound. Up until a few days ago, >I had incorporated all the comments I'd received except for >some style comments I was reviewing from Keith. > >The problem I see is that we have two separate communities >using the outbound draft: > >1) folks that want to get through NATs and Firewalls in the >public Internet at large - they want to use TCP and TLS with >double CRLF for keepalives. One "flow" is always one >connection. The milestone for this would read "Make TCP and >TLS work in the Internet". > >2) folks that want UDP to work through specific NATs even if >the edge proxy, NAT, or interface hiccups - some of these >folks want to treat multiple IPsec SAs so the definition of >"flow" becomes terribly fuzzy to everyone else, and they need >to use STUN keepalives. > > >I would like to use this opportunity to point out that if we >said "out of scope for now" to outbound over UDP then we would >already be done now and there would already be multiple >implementations, including one that I started for the repro >open source proxy. We would have sidestepped the fuzzy "flow" >terminology and all the endless debates about STUN keepalive >usage and discovery, since double CRLF is fully backwards >compatible with even RFC 2543 implementations. I am bringing >this up on the list because I hope the WG can look back on >this and not make the mistake of snowballing complexity to >preserve UDP parity again in the future. > > >At this point, I believe that these decisions are water under >the bridge. I would like to explore ways forward: > >FASTEST (hold nose and swallow): >Normatively RECOMMEND using congestion-safe transports for outbound. >Point out that if you only use UDP flows you can't switch over >to TCP, and that using a UDP flow when you have a perfectly >good TCP flow is complete silliness. I'll point out that TCP >has been mandatory to implement in both UAs and proxies for 4 years. > >CLEANEST (the 2 more years! approach): >Split outbound up so that we have at least three drafts: >a) an update to Path that uses a reg-id to store multiple >bindings/paths back to a UA regardless of transport. this is >useful in the multiple radio interface use case for example >even if there are no NATs. >b) a STUN keep-alive draft - with or without discovery. I'm >not writing it--I think it is a terrible idea. >c) outbound *connections* draft for TCP and TLS over TCP only. > (If you want outbound for SCTP you can write your own damn draft). >d) possibly a SIP over UDP NAT traversal draft. Again, I have >no interest in working on a draft with this kind of draft. > >If you think you have a clever/better proposal than one of >these, please send me private mail or phone me. > >Please send comments to the list or directly to me. If you >support one of these two approaches, please put FASTEST or >CLEANEST in the first line of the message. > >thanks, >-rohan > > >On Nov 20, 2006, at 0:25, Aki Niemi wrote: >> ma, 2006-11-20 kello 06:57 +0100, ext Christer Holmberg (JO/LMF) >> kirjoitti: >>> Hi, >>> >>>> The outbound draft needs to say: "if a UA establishes a flow using >>>> an >>> unreliable transport, it MUST also establish one >>>> over a reliable transport" (to support switch over). >>> >>> I think it's enough to have a recommendation. In some cases it may >>> not be possible/feasible to establish a TCP connection - no >matter if >>> you use outbound or not. >> >> Please enumerate the cases. >> >> Unless there are concrete cases where TCP simply does not work, I >> would strongly recommend we drop UDP from outbound altogether. >> Remember, UDP already kind of works in presence of NAT; this >is why we >> have for instance rport. >> >> Dropping UDP as a choice in outbound will make the decision >to drop it >> from SIP a lot easier in the long run. Then again, keeping it in >> outbound will all but guarantee it will be absolutely >tedious ripping >> it out later on. >> >> Oh, and if we did drop UDP, then the choice of the keepalive >mechanism >> becomes, well, interesting. ;) >> >> Cheers, >> Aki >> > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 03:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRLH-0001oq-Pl; Tue, 21 Nov 2006 03:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRLF-0001ol-Eu for sip@ietf.org; Tue, 21 Nov 2006 03:50:57 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmRLE-0005tv-63 for sip@ietf.org; Tue, 21 Nov 2006 03:50:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id E4A203BEDD; Tue, 21 Nov 2006 09:50:33 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04059-01-42; Tue, 21 Nov 2006 09:50:33 +0100 (CET) Received: from [192.168.123.17] (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 27C873BE69; Tue, 21 Nov 2006 09:50:28 +0100 (CET) Message-ID: <4562BDC0.8090105@it.su.se> Date: Tue, 21 Nov 2006 09:50:08 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <7374777208BDC7449D5620EF942325676E738F@esealmw113.eemea.ericsson.se> <1164011130.7342.9.camel@macbuster.research.nokia.com> <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> In-Reply-To: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.564 tagged_above=-99 required=7 tests=[AWL=0.101, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FASTEST I think it really WILL be two more years if we go for "cleanest", and I don't even see it as a loss to solve the problem for only those transports where it is solved easily. What is the _real_ reason that user agents only implement UDP, anyway? Most of them have TCP stacks already (for web browsing in mobile phones, and web interfaces in other), and even though it is harder to do message de-framing yourself, it isn't _that_ hard. In my implementation I do TCP message de-framing in less than 130 lines of code. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 06:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTRz-0005Uo-3w; Tue, 21 Nov 2006 06:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTRy-0005Ue-HB for sip@ietf.org; Tue, 21 Nov 2006 06:06:02 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmTRq-00027t-Vs for sip@ietf.org; Tue, 21 Nov 2006 06:06:02 -0500 Received: (qmail invoked by alias); 21 Nov 2006 11:05:53 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 21 Nov 2006 12:05:53 +0100 X-Authenticated: #29516787 Message-ID: <4562DD96.5000700@gmx.net> Date: Tue, 21 Nov 2006 12:05:58 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: IETF SIP List , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: Subject: [Sip] Comments regarding draft-ietf-sip-location-conveyance-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, Hi James, I have reviewed the document. First, I would like to thank you for improving the document. But, I still have a few comments: Questions: You write: " A dereference of a location-by-reference URI using SUBSCRIBE is not violating a PIDF-LO 'retransmission-allowed' element value set to 'no', as the NOTIFY is the only message in this multi-message series of transactions that contains the UAC's location, with the location recipient being the only SIP element to receive location - which the purpose of this extension: to convey location to a specific destination. " I wasn't quite sure what you are about to say with this statement. If the Location Recipient receives a reference and it resolves it then you are saying that this is OK even if the retransmission-allowed flag says "no". Correct? Technical Aspects: * Proxy Usage When a proxy adds a reference to a PIDF-LO then a number of issues remain unclear (as discussed throughout the Geopriv work), namely: - What does the PIDF-LO contain that is created by the SIP proxy? * How does the proxy know that location information has to be added? - There is a privacy problem if the SIP proxy acts without explicit indication that location information is added. * Using Protocol You write: " Other protocols used in the Location URI MUST be reviewed against the RFC3693 criteria for a using protocol. " Later, in Section 3.6 you write: " Use of other protocols for dereferencing of a pres: URI is not defined, and such use is subject to review against RFC3693 using protocol criteria. " I disagree that the protocol used to resolve the reference has to be a using protocol. Hence, I suggest to delete this sentence. * Privacy Rules You write: " Entities receiving location information MUST honor the usage element rules per RFC4119. Such entities MUST NOT alter the rule set. " The last sentence is not correct. Let me give you an example: A SIP UAC obtains location information from GPS and uses a PUBLISH to upload the PIDF-LO to the Location Server/ Presense Server. This server has rules that control access to location information. As part of these rules the content of the Location Object including the rules might be modified. * The examples pick unfortunate references (sips:server5.atlanta.example.com/alice123) that give me the impression that the reference contains the user identity. The document clearly needs to point out that this is not the case. The document also does not indicate that the reference is only kept for a certain period of time (soft-state). The document does not even mention security aspects when retrieving the reference. * Security in Section 5 SIP Element Behavior I am confused with the text in Section 5. What MUST and what SHOULD be used when protecting a location-by-value and a location-by-reference? SHOULD for TLS usage with location-by-value and location-by-reference. No statement about usage of S/MIME. I wonder why self-signed certificates shouldn't be used as stated with: " Self-signed certificates SHOULD NOT be used for protecting PIDF, as the sender does not have a secure identity of the recipient. " For encryption (and that's what we are talking about here) it heavily depends on the way how the self-signed certificate was obtained. I might share my certificate with you and hence that's an extemely useful way todo compared to the usage of TLS in a hop-by-hop way where a number of entities see my location along the path. Identity info in the PIDF. In previous discussion I was wondering and asking the Geopriv group whether there is some semantic associated with the identity in the PIDF. If there is, then you cannot put anything you like into the PIDF. If there isn't then why should we ever want to put something meaningful in there since it greatly impacts the privacy risks. I see a problem with retargeting and forking where the Location Recipient is actually not know ahead of time and S/MIME usage is actually not really feasible. Would some guidance be useful? * Section 7. The document refers to 'using protocols' for both the UAC <-> UAS and to the dereferencing protocol. I assume that Section 7 only addresses the UAC <-> UAS communication. Since I am in favor of not treating the derefencing protocol a 'using protocol' I am fine with it. Actually, I would prefer to move Section 7 into the appendix since this is just such an artifical story that it makes me nervous. It is not your fault; it is just the way how RFC 3693 was written. * The security consideration section isn't particularly good. If I have time I rewrite it. Editorial Aspects: The term 'Location' is written with a capital letter (see for example first paragraph in Section 1) whereas other RFC3693 terms that are meant to be written with a capital letter aren't (example: 'target', 'location object', 'using protocol', 'location recipient'). I suggest to stick with RFC3693. " This document describes how Location can be "conveyed" (that is, sent on the Internet) from a SIP user agent, or in some circumstances a proxy server acting on behalf of a user agent, to another entity using the SIP [RFC3261] protocol. ^^^^^^^^^^^^^^^^^^^^^^^^^^ " Either write using SIP [..] or using the Session Initiation Protocol [...]. I suggest to rewrite the following paragraph from: " As recited in RFC3693, location often must be kept private. The location object (PIDF-LO) contains rules which are binding on the location recipient and controls onward distribution and retention of the location. This document describes the security and privacy considerations that must be applied to location conveyed with SIP. " to: " The Location Object contains rules which provide guidance for the Location Recipient on the onward distribution and retention of the received location information. This document describes the security and privacy considerations that must be applied to location conveyed with SIP. " I don't know what this sentence should mean in Section 1 at this part of the section. " Often, location is sent from the User Agent Client to the User Agent Server, or vice versa for purposes that are beyond the scope of this document. " There seems to be a copy-and-paste problem. You write: " The Geolocation header is introduced to signify that location is included in a SIP message to provide either a content identifier (cid:) pointer to the body part containing the UAs PIDF-LO, or a location-by-reference URI that may subsequently be "dereferenced" by a using protocol (which may be SIP or another protocol). " Please delete the following part " by a using protocol (which may be SIP or another protocol)" since we haven't concluded in our discussion that the dereferencing protocol is indeed a using protocol. Actually, I think that the entire paragraph is not particularly useful in the introduction and the subsequent paragraph fits much better to the previous one. You write: " The Geolocation header MUST contain one two types of URIs: ^^^^^^^^^^^^ one of two types " The example contains a company name (www.cisco.com) although it should, according to the guidelines something like "www.example.com". Section 4.3 uses the term 'LIS' and does not mention what it is. Just avoid it. IDNITS: Experimental warnings: - Missing Reference: 'RFC3851' is mentioned on line 343, but not defined 'resulting resolution, per [RFC3851], resolves to a sip: or sips:...' - Unused Reference: 'ID-Loc-Reg' is defined on line 891, but not referenced '[ID-Loc-Reg]...' Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages tmp/draft-ietf-sip-location-conveyance-05.txt(294): Line has weird spacing: '... Rr ar ...' tmp/draft-ietf-sip-location-conveyance-05.txt(298): Line has weird spacing: '... Rr ar ...' Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From caseyflin@wnhd.com Tue Nov 21 06:44:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmU3T-0002D6-Cj for sip-archive@lists.ietf.org; Tue, 21 Nov 2006 06:44:47 -0500 Received: from pd9ecd95c.dip.t-dialin.net ([217.236.217.92] helo=ggkc) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmU3R-0005ty-1x for sip-archive@lists.ietf.org; Tue, 21 Nov 2006 06:44:47 -0500 Message-ID: <00a601c70d5b.8fda9380.cd5cc0a8@zackariah> Date: Tue, 21 Nov 2006 10:55:31 +0000 From: ally madelina User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: codie eva Subject: CBFE Be respected Content-Type: multipart/alternative; boundary="---------0000000C.01C70D5B" X-Spam-Score: 2.4 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. -----------0000000C.01C70D5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CBFE CBFE CBFE CBFE CBFE CBFE Company: CHINA BIOLIFE ENTERP (CBFE.PK) Symbol: CBFE Price: $0.10 Rating: Agressive Buy Target: $1 IT IS NOT TOO LATE TO GET IN THE BOOMING BIO SECTOR! CBFE, A CHINA BASED COMPANY PRESENTS YOU WITH THIS OPPORTUNITY! DON'T MISS OUT THE CHANCE OF MAKING SICK PROFITS! WATCH CBFE TRADE ON TUESDAY NOVEMBER 21! -----------0000000C.01C70D5B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
CBFE CBFE CBFE CBFE CBFE CBFE


Company: CHINA BIOLIFE ENTERP (CBFE.PK)
Symbol: CBFE
Price: $0.10
Rating: Agressive Buy
Target: $1

IT IS NOT TOO LATE TO GET IN THE BOOMING BIO SECTOR!
CBFE, A CHINA BASED COMPANY PRESENTS YOU WITH THIS OPPORTUNITY!
DON'T MISS OUT THE CHANCE OF MAKING SICK PROFITS!


WATCH CBFE TRADE ON TUESDAY NOVEMBER 21!
-----------0000000C.01C70D5B-- From sip-bounces@ietf.org Tue Nov 21 08:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVmS-0001Ly-Ua; Tue, 21 Nov 2006 08:35:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVmQ-0001J3-4e; Tue, 21 Nov 2006 08:35:18 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmVmM-0003k4-DX; Tue, 21 Nov 2006 08:35:18 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GmVmF-0005JA-To; Tue, 21 Nov 2006 07:35:08 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'IETF SIP List'" , "'GEOPRIV'" Date: Tue, 21 Nov 2006 08:35:07 -0500 Message-ID: <01dd01c70d71$dec7a580$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccNXRd0ROIDpaUATgWMBcUd+j55ggADTP+g In-Reply-To: <4562DD96.5000700@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Cc: Subject: [Sip] RE: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for your detailed review comments. My views are inline. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, November 21, 2006 6:06 AM > To: IETF SIP List; GEOPRIV > Subject: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance- > 05.txt > > Hi Brian, > Hi James, > > I have reviewed the document. > > First, I would like to thank you for improving the document. But, I > still have a few comments: > > Questions: > > > You write: > " > > A dereference of a location-by-reference URI using SUBSCRIBE is not > violating a PIDF-LO 'retransmission-allowed' element value set to > 'no', as the NOTIFY is the only message in this multi-message series > of transactions that contains the UAC's location, with the location > recipient being the only SIP element to receive location - which the > purpose of this extension: to convey location to a specific > destination. > " > > I wasn't quite sure what you are about to say with this statement. If the > > Location Recipient receives a reference and it resolves it then you are > > saying that this is OK even if the retransmission-allowed flag says "no". > > Correct? Yes, correct. In fact if 3 proxies on the path sequentially resolve the reference when retransmission-allowed='no' that is okay. However, none of those proxies may retransmit the location. > > > Technical Aspects: > > * Proxy Usage > > When a proxy adds a reference to a PIDF-LO then a number of issues remain > > unclear (as discussed throughout the Geopriv work), namely: > > - What does the PIDF-LO contain that is created by the SIP proxy? First of all, you are making an assumption that the proxy creates the value returned by the reference it adds. That is not likely the case. It's more likely that the proxy has access to a LIS which supplies it the reference to include. I think the reference resolves to the same PIDF-LO that the LIS would have given the endpoint. If indeed the proxy actually is the dereference agent, then it would return a PIDF-LO that would look exactly like a LIS would provide. I'm expecting such a PIDF-LO would have very few of the fields defined in PIDF. For example, a "Contact" is unlikely to be present. Most importantly, I think the proxy, like the LIS, has to include a ruleset that conforms to the preferences of the target. I'm not sure that there needs to be any text in conveyance that says that. > > > * How does the proxy know that location information has to be added? > > - There is a privacy problem if the SIP proxy acts without explicit > > indication that location information is added. The use case we know about is the emergency case, where location is not provided by the endpoint and the proxy knows where the endpoint is. The only circumstance that is likely to be true is where the SIP network and the access network are the same domain, or they have pre-established relationship, and a way of correlating identifiers such that the SIP network can get the correct location (or reference). Here, perhaps we need text that explains this. I had expected this would appear in ecrit-framework, but I'm not sure now that it's a good idea to limit proxy add of location to the emergency case. I do think we get into pretty serious sticky wickets with what we can say for the non-emergency case. I would expect we have to say that the proxy has explicit permission, and a ruleset by the target for the location it is adding, but that doesn't really express the wishes of the target of WHEN it is okay to add location. > > > * Using Protocol > > You write: > " > Other protocols used in the Location URI MUST be reviewed against > the RFC3693 criteria for a using protocol. > " > > Later, in Section 3.6 you write: > " > Use of other protocols for dereferencing > of a pres: URI is not defined, and such use is subject to review > against RFC3693 using protocol criteria. > " > > I disagree that the protocol used to resolve the reference has to be a > using > > protocol. Hence, I suggest to delete this sentence. Well, perhaps this should be discussed in the LbyR design team. Certainly, the location value is carried in the protocol. I don't understand how it could not be viewed as a using protocol. > > > * Privacy Rules > > You write: > " > Entities receiving location information MUST honor the usage element > rules per RFC4119. Such entities MUST NOT alter the rule set. > " > > The last sentence is not correct. Let me give you an example: A SIP UAC > > obtains location information from GPS and uses a PUBLISH to upload the > > PIDF-LO to the Location Server/ Presense Server. This server has rules > that > > control access to location information. As part of these rules the content > > of the Location Object including the rules might be modified. While I can imagine a way to express a rule that modifies the ruleset, I don't think we have ever discussed that kind of rule. If we allow such things that we need some pretty convoluted language. If you want such a capability, then please propose wording that permits a rule to modify a rule set, but doesn't allow an arbitrary modification of the ruleset and show me some other place where we have used that language. This has to be the same as, for example, presence. > > > * The examples pick unfortunate references > (sips:server5.atlanta.example.com/alice123) > that give me the impression that the reference contains the user identity. > The document clearly needs to point out that this is not the case. The I think this is a good point and we should modify the example text. > document also does not indicate > > that the reference is only kept for a certain period of time (soft-state). > The document does not even mention security aspects when retrieving the > > reference. The notion of a time limited reference is specific to the scheme. It was proposed in Henning (et al)'s SIP based LCP for example, but not in all LbyR mechanisms. I don't know if -conveyance is the right place to discuss that issue. We don't have any mechanism that discusses how long any element should keep a reference, regardless of whether the dereference mechanism has an expiration. Another LbyR design team topic? I'd prefer that -conveyance not be the place that defines such things. > > > * Security in Section 5 SIP Element Behavior > > I am confused with the text in Section 5. What MUST and what SHOULD be > used > > when protecting a location-by-value and a location-by-reference? > > SHOULD for TLS usage with location-by-value and location-by-reference. Yeah, we should clean up the language here. I think both. > No statement about usage of S/MIME. Right. Need some text that S/MIME SHOULD be used to protect a value or reference if the intention is that the only element that should get it is the opposite UA. > > I wonder why self-signed certificates shouldn't be used as stated with: > " > Self-signed certificates SHOULD NOT be used for protecting PIDF, > as the sender does not have a secure identity of the recipient. > " > For encryption (and that's what we are talking about here) it heavily > > depends on the way how the self-signed certificate was obtained. I might > > share my certificate with you and hence that's an extemely useful way todo > > compared to the usage of TLS in a hop-by-hop way where a number of > entities > > see my location along the path. Perhaps you would send some text to cover this case. I tried a couple of ways and didn't think my attempts made any sense. > > Identity info in the PIDF. In previous discussion I was wondering and > asking > > the Geopriv group whether there is some semantic associated with the > > identity in the PIDF. If there is, then you cannot put anything you like > > into the PIDF. If there isn't then why should we ever want to put > something > > meaningful in there since it greatly impacts the privacy risks. I don't understand this. If it's LbyV and the endpoint puts it in, then it controls the identity, and it CAN put anything it wants to. In a case of LbyR, then the LIS, or whomever is constructing the PIDF needs a mechanism to allow the target to specify a ruleset, and probably needs to allow it to specify the identity as well. > > I see a problem with retargeting and forking where the Location > Recipient is actually not know ahead of time and S/MIME usage is > actually not really feasible. Would some guidance be useful? Not sure I know what you mean. I've long considered the problem that the hop by hop mechanism allows any proxy on the path to see location, but it also allows the opposite UA to see it. There isn't a way to say "I trust the proxies, but I don't trust the endpoint". On the other hand, retarget/fork may be precisely the reason S/MIME can't be used, and TLS is very appropriate. I do think at least mentioning the issue here is warranted. I don't see need for more mechanism. > > * Section 7. > > The document refers to 'using protocols' for both the UAC <-> UAS and to > the dereferencing protocol. I assume that Section 7 only addresses the > UAC <-> UAS communication. Since I am in favor of not treating the > derefencing protocol a 'using protocol' I am fine with it. > > Actually, I would prefer to move Section 7 into the appendix since this > is just such an artifical story that it makes me nervous. It is not your > fault; it is just the way how RFC 3693 was written. See above; I fail to see how the dereference can possibly avoid being a using protocol. > > * The security consideration section isn't particularly good. If I have > time I rewrite it. Suggestions are welcome. Send text, or at least talking points. > > > > Editorial Aspects: > > The term 'Location' is written with a capital letter (see for example > first > > paragraph in Section 1) whereas other RFC3693 terms that are meant to be > > written with a capital letter aren't (example: 'target', 'location > object', > > 'using protocol', 'location recipient'). I suggest to stick with RFC3693. Good point. We'll fix this. > > > " > This document describes how Location can be "conveyed" (that is, > sent on the Internet) from a SIP user agent, or in some > circumstances a proxy server acting on behalf of a user agent, to > another entity using the SIP [RFC3261] protocol. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > " > > Either write using SIP [..] or using the Session Initiation Protocol > [...]. Okay > > > I suggest to rewrite the following paragraph from: > > " > As recited in RFC3693, location often must be kept private. The > location object (PIDF-LO) contains rules which are binding on the > location recipient and controls onward distribution and retention of > the location. This document describes the security and privacy > considerations that must be applied to location conveyed with SIP. > > " > > to: > > " > The > Location Object contains rules which provide guidance for the Location > > Recipient on the onward distribution and retention of > the received location information. This document describes the > security > > and privacy > considerations that must be applied to location conveyed with SIP. > " I don't understand your objection to the text as written. Are you objecting to the reference to 3693, the explicit mention of PIDF-LO, the word "binding" or something else? > > > I don't know what this sentence should mean in Section 1 at this part of > the > > section. > " > Often, location is sent from the User Agent Client to the User Agent > Server, or vice versa for purposes that are beyond the scope of this > document. > " > > There seems to be a copy-and-paste problem. We'll look at it > > > You write: > > " > The Geolocation header is introduced to signify that location is > included in a SIP message to provide either a content identifier > (cid:) pointer to the body part containing the UAs PIDF-LO, or a > location-by-reference URI that may subsequently be "dereferenced" by > a using protocol (which may be SIP or another protocol). > " > > Please delete the following part " by > a using protocol (which may be SIP or another protocol)" since we > haven't > > concluded in our discussion that the dereferencing protocol is indeed a > > using protocol. See above > > Actually, I think that the entire paragraph is not particularly useful in > > the introduction and the subsequent paragraph fits much better to the > > previous one. > > > You write: > " > The Geolocation header MUST contain one two types of URIs: > ^^^^^^^^^^^^ > one of two types > " OK > > > The example contains a company name > > (www.cisco.com) although it should, > > according to the guidelines something like "www.example.com". OK > > > Section 4.3 uses the term 'LIS' and does not mention what it is. > Just avoid it. Hmmm. We really do have to agree on terminology, no question. The notion that LIS is not acceptable is very disconcerting. Outside of IETF, LIS is a well understood term. Location Generator is not. > > > IDNITS: > > Experimental warnings: > - Missing Reference: 'RFC3851' is mentioned on line 343, but not > defined > 'resulting resolution, per [RFC3851], resolves to a sip: or sips:...' > > - Unused Reference: 'ID-Loc-Reg' is defined on line 891, but not > > referenced > '[ID-Loc-Reg]...' Will fix > > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > - It seems as if not all pages are separated by form feeds - found 0 > form > feeds but 26 pages Hmmm, tool problem. James uses the Word template. > > > tmp/draft-ietf-sip-location-conveyance-05.txt(294): Line has weird > spacing: > > '... Rr ar ...' > tmp/draft-ietf-sip-location-conveyance-05.txt(298): Line has weird > spacing: > > '... Rr ar ...' OK _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 11:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmY2b-0004ag-5k; Tue, 21 Nov 2006 11:00:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmY2Z-0004aB-6Y for sip@ietf.org; Tue, 21 Nov 2006 11:00:07 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmY2G-0002Kw-VV for sip@ietf.org; Tue, 21 Nov 2006 11:00:07 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALFCRe6012493; Tue, 21 Nov 2006 17:14:00 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 17:11:03 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 17:11:03 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound open issues from IETF 67 Date: Tue, 21 Nov 2006 17:11:04 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03060C56@esebe103.NOE.Nokia.com> In-Reply-To: <15201.12.151.41.2.1164050440.squirrel@12.151.41.2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound open issues from IETF 67 Thread-Index: AccM2vJiy3PjIkueQJ+nLnCBrLAx5wAobaYg From: To: , X-OriginalArrivalTime: 21 Nov 2006 15:11:03.0210 (UTC) FILETIME=[429028A0:01C70D7F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, I do not have any objections to any of the proposals you made for Outbound. However I have a question related to the Issue 3G you had on your slideset. The slideset outlined the 3GPP requirement as follows: - 3GPP and others want to store multiple path vectors back to an instance, each associated with a reg-id. - New registrations with the same reg-id would replace the old binding. * BUT 3GPP wants to do this unrelated to outbound flow-token processing * 3GPP wants separation of binding behavior and flow-token behavior=20 * Why? Their IPsec UDP uses several pairs of actual flows, instead of just one. In 3GPP there is also a backwards compatibility issue related to the IPSec SA management in the edge proxy (P-CSCF). Old implementations not supporting Outbound would drop the old=20 logical flow (IPSec SA) if the UA registers with a new reg-id and IP address. Thus the UA should be able to make sure that=20 the edge proxy supports the new behaviour, before trying to establish multiple flows over different access networks towards the single edge proxy. They have been proposing a new option tag for this purpose, something like this: Name: mreg Description: This option-tag is used to identify SIP servers which are able to maintain multiple logical flows per UA instance. What do you think about this proposal ?=20 Regards, Erkki >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan@ekabal.com]=20 >Sent: 20.November.2006 21:21 >To: sip@ietf.org >Cc: Rohan Mahy >Subject: [Sip] outbound open issues from IETF 67 > >Hi Folks, > >I've incorporated all the changes we agreed to at IETF67. For=20 >those who >have not seen them yet, please consult the slides available here: >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf > >In addition, I have proposed text for Issues D&E (see below). > >In summary, we agreed from the meeting: >- Consensus to use 430 response >- Consensus to keep the "stable flow timer" >Bug A: No objection to fixing this bug >Issue B: consensus to only require 1st hop and registrar to participate >Issue C: consensus for No Action >Issue D: did not discuss, proposal mentioned below >Issue E: did not discuss, proposal mentioned below >Issue F: consensus for No Action >Issue 3G: rough consensus to Accept action 2 > >(Bug A): Provided mention of the 'rport' parameter. > >(Issue 3G): Relaxed flow-token language slightly. Instead of flow-token >saving specific UDP address/port tuples over which the request arrived, >make language fuzzy to save token which points to a 'logical=20 >flow' that is >known to deliver data to that specific UA instance. > >(Issue B): Changed registrar verification so that only=20 >first-hop proxy and >the registrar need to support outbound. Other intermediaries=20 >in between >do not any more. > >(Issues D&E): Proposal text: >The UAC can situationally decide whether to request outbound=20 >behavior by >including or omitting the 'reg-id' parameter. For example, imagine the >outbound-proxy-set contains two proxies in different domains,=20 >EP1 and EP2. > If an outbound-style registration succeeded for a flow=20 >through EP1, the >UA might decide to include 'outbound' in its option-tag when=20 >registering >with EP2, in order to insure consistency. Similarly, if the=20 >registration >through EP1 did not support outbound, the UA might decide to omit the >'reg-id' parameter when registering with EP2. > >I believe the proposed text for D&E is sufficient and should be fairly >non-controversial. If anyone has any objections, please speak up ASAP >(and *send text* ;-). > >thanks, >-rohan > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 12:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZWF-00089z-Hu; Tue, 21 Nov 2006 12:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZWE-00089t-GZ for sip@ietf.org; Tue, 21 Nov 2006 12:34:50 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZWD-00010p-3q for sip@ietf.org; Tue, 21 Nov 2006 12:34:50 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id kALHYl8o017963 for ; Tue, 21 Nov 2006 10:34:48 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Tue, 21 Nov 2006 10:34:47 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Nov 2006 10:34:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requesting feedback on draft-dotson-sip-certificate-auth-01 Thread-Index: AccNk1aBHIBGrGjpQpuIDMODz77mnQ== From: "Steve Dotson" To: "IETF SIP List" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Sip] Requesting feedback on draft-dotson-sip-certificate-auth-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0586333383==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0586333383== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70D93.56DFBC04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70D93.56DFBC04 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some industries and organizations have invested in PKI, and thus have certificates available for authentication. We would like to leverage those credentials for SIP authentication. Using certificates instead of UICCs or other credentials is attractive for certain deployment models. http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-01 .txt describes some requirements related to this issue, as well as a review of previous and related work. We have received good feedback offline from authors of related work which were incorporated into the latest draft. =20 Thanks, =20 Steve. =20 ------_=_NextPart_001_01C70D93.56DFBC04 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Some = industries and=20 organizations have invested in PKI, and thus have certificates available = for=20 authentication. We would like to leverage those credentials for SIP=20 authentication. Using certificates instead of UICCs or other = credentials is=20 attractive for certain deployment models. http://www.ietf.org/internet-drafts/draft-dotson-sip-certifi= cate-auth-01.txt describes=20 some requirements related to this issue, as well as a review of previous = and=20 related work. We have received good feedback offline from authors = of=20 related work which were incorporated into the latest = draft.
 

Thanks,

 

Steve.

 

------_=_NextPart_001_01C70D93.56DFBC04-- --===============0586333383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0586333383==-- From sip-bounces@ietf.org Tue Nov 21 13:12:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma4k-0006Jx-BX; Tue, 21 Nov 2006 13:10:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma4i-0006Io-OK for sip@ietf.org; Tue, 21 Nov 2006 13:10:28 -0500 Received: from empbedex1.empirix.com ([12.38.203.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gma4f-000735-BC for sip@ietf.org; Tue, 21 Nov 2006 13:10:28 -0500 Received: from EMPBEDEX.empirix.com ([10.16.0.92]) by empbedex1.empirix.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 13:10:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO call flow Date: Tue, 21 Nov 2006 13:10:03 -0500 Message-ID: In-Reply-To: <002d01c70d32$aa4e90f0$241c320a@telxsi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO call flow Thread-Index: AccNM4+hoYx902X9Rd+0GYa7lqxM4AAYtJGg From: "Bhattacharyya, Dipankar" To: "Varsha Kulkarni" , X-OriginalArrivalTime: 21 Nov 2006 18:10:10.0845 (UTC) FILETIME=[48A71CD0:01C70D98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Varsha, The Call Flow in section 3.3.1 of the draft is a standard call between two PSTN subscribers wherein there is IP transport between the two GWs servicing the two PSTN Subscribers. So like a normal PSTN to SIP Call here is the step1 of the call below where both side are connected : Orig PSTN Ingress GW SIP Server Egress GW Dest PSTN GW1 SPS GW2 ------------>------------>------------>------------> IAM Invite Invite IAM <-----------<------------<------------<------------ ACM 180 Ringing 180 Ringing ACM <-----------<------------<------------<------------ ANM 200 OK 200 OK ANM ------------>------------> ACK ACK After the above A to B is connection is setup then Receiving side PSTN subscriber sends a ISUP Message called USR ( User-to-User-Information only relevant to ITU-TS not ANSI SS7 ). This USR information may be expiration of the Called and calling party's credit in case they are prepaid subscribers or the USR message may be update of account balance as well. The ISUP USR Message is carried over the IP n/w as a SIP INFO Message with ISUP Message body to the originating side. =20 <-----------<------------<------------<------------ USR INFO INFO USR ISUP MIME ISUP MIME USR USR ------------>------------> 200 OK 200 OK ------------>------------>------------>------------> USR INFO INFO USR ISUP MIME ISUP MIME USR USR <------------<------------ 200 OK 200 OK Also I guess you are probably aware that the draft is now a RFC 2976 and also I would suggest that also go thru RFC 3398 for more use cases of ISUP to SIP Mapping.=20 =20 Dipankar Bhattacharyya=20 Systems Engineer=20 EMPIRIX=20 p: 972.491.0555 f: 972.491.0553 m: 214.766.1479 email: dbhattacharyya@empirix.com 7200 Preston Rd., # 921 - Plano, TX 75024 http://www.empirix.com=20 -----Original Message----- From: Varsha Kulkarni [mailto:varshakulkarni@tataelxsi.co.in]=20 Sent: Tuesday, November 21, 2006 12:03 AM To: sip@ietf.org Subject: [Sip] INFO call flow Hello, Please explain the call flow given in 3.3.1 of Internet Draft by Steve Donovan draft-ietf-sip-info-method-00.txt MCI Worldcom October 1999. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 13:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmaUz-0007CS-87; Tue, 21 Nov 2006 13:37:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmaUy-0007CM-Fl for sip@ietf.org; Tue, 21 Nov 2006 13:37:36 -0500 Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmaUv-0004Qj-4a for sip@ietf.org; Tue, 21 Nov 2006 13:37:36 -0500 Received: from smtptpa3.verizon.com (smtptpa3.verizon.com [138.83.71.176]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id kALIbwBQ009624 for ; Tue, 21 Nov 2006 13:37:58 -0500 (EST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id kALIbSD6018595 for ; Tue, 21 Nov 2006 13:37:28 -0500 (EST) Received: from coregate1.verizon.com (unknown [138.83.34.22]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id AB9CE444002 for ; Tue, 21 Nov 2006 13:37:28 -0500 (EST) Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id kALIbUSo027199 for ; Tue, 21 Nov 2006 12:37:32 -0600 (CST) From: nabeel.2.cocker@verizon.com To: sip@ietf.org Message-ID: Date: Tue, 21 Nov 2006 13:37:25 -0500 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 7.0.2|September 26, 2006) at 11/21/2006 12:37:27 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Nabeel 2. Cocker/EMPL/NY/Bell-Atl is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be out of the office starting 11/20/2006 and will not return until 11/27/2006. I will respond to your message when I return. Regards, Nabeel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 14:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbeu-0000Vh-Sx; Tue, 21 Nov 2006 14:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbet-0000Vb-CW for sip@ietf.org; Tue, 21 Nov 2006 14:51:55 -0500 Received: from hu-out-0506.google.com ([72.14.214.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmbeq-0001gK-Rm for sip@ietf.org; Tue, 21 Nov 2006 14:51:55 -0500 Received: by hu-out-0506.google.com with SMTP id 38so1359041huc for ; Tue, 21 Nov 2006 11:51:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MafZ12rPQzBxE7Kp68M1omoZK8t1Hymsmn/Ftq+yg8+APA4LsRNhDmj5prDHzMRaDw7Ezz0UzRED9bezTBbxl27Be2lUbNyZAkUiSk1U9H2W0A3oP0JmIRPhnufGUWd1wvQ/JYMfcgRozqke19P5YS1k+eR95z1nuJmJ0ayttHs= Received: by 10.78.128.11 with SMTP id a11mr6866664hud.1164138711152; Tue, 21 Nov 2006 11:51:51 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 21 Nov 2006 11:51:50 -0800 (PST) Message-ID: <953beacc0611211151t472c88aegcdef5e8781d905fb@mail.gmail.com> Date: Tue, 21 Nov 2006 11:51:50 -0800 From: "Rohan Mahy" To: "Erkki.Koivusalo@nokia.com" Subject: Re: [Sip] outbound open issues from IETF 67 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03060C56@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <15201.12.151.41.2.1164050440.squirrel@12.151.41.2> <8B1D53AEF7B03449A6D3771B3B7F850F03060C56@esebe103.NOE.Nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, If the first hop edge proxy (the P-CSCF) doesn't support outbound, it will not add the 'ob' parameter to the Path header, so the registrar will ignore the reg-id parameter in the request. hope this helps. thanks, -rohan On 11/21/06, Erkki.Koivusalo@nokia.com wrote: > > Hi Rohan, > > I do not have any objections to any of the proposals you made > for Outbound. However I have a question related to the Issue 3G > you had on your slideset. The slideset outlined the 3GPP requirement > as follows: > > - 3GPP and others want to store multiple path vectors back to an > instance, each associated with a reg-id. > - New registrations with the same reg-id would replace the old binding. > * BUT 3GPP wants to do this unrelated to outbound flow-token > processing > * 3GPP wants separation of binding behavior and flow-token > behavior > * Why? Their IPsec UDP uses several pairs of actual flows, > instead of just one. > > In 3GPP there is also a backwards compatibility issue related > to the IPSec SA management in the edge proxy (P-CSCF). Old > implementations not supporting Outbound would drop the old > logical flow (IPSec SA) if the UA registers with a new reg-id > and IP address. Thus the UA should be able to make sure that > the edge proxy supports the new behaviour, before trying to > establish multiple flows over different access networks > towards the single edge proxy. > > They have been proposing a new option tag for this purpose, > something like this: > > Name: mreg > Description: This option-tag is used to identify SIP servers which > are able to maintain multiple logical flows per UA instance. > > What do you think about this proposal ? > > Regards, > > Erkki > > >-----Original Message----- > >From: ext Rohan Mahy [mailto:rohan@ekabal.com] > >Sent: 20.November.2006 21:21 > >To: sip@ietf.org > >Cc: Rohan Mahy > >Subject: [Sip] outbound open issues from IETF 67 > > > >Hi Folks, > > > >I've incorporated all the changes we agreed to at IETF67. For > >those who > >have not seen them yet, please consult the slides available here: > >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf > > > >In addition, I have proposed text for Issues D&E (see below). > > > >In summary, we agreed from the meeting: > >- Consensus to use 430 response > >- Consensus to keep the "stable flow timer" > >Bug A: No objection to fixing this bug > >Issue B: consensus to only require 1st hop and registrar to participate > >Issue C: consensus for No Action > >Issue D: did not discuss, proposal mentioned below > >Issue E: did not discuss, proposal mentioned below > >Issue F: consensus for No Action > >Issue 3G: rough consensus to Accept action 2 > > > >(Bug A): Provided mention of the 'rport' parameter. > > > >(Issue 3G): Relaxed flow-token language slightly. Instead of flow-token > >saving specific UDP address/port tuples over which the request arrived, > >make language fuzzy to save token which points to a 'logical > >flow' that is > >known to deliver data to that specific UA instance. > > > >(Issue B): Changed registrar verification so that only > >first-hop proxy and > >the registrar need to support outbound. Other intermediaries > >in between > >do not any more. > > > >(Issues D&E): Proposal text: > >The UAC can situationally decide whether to request outbound > >behavior by > >including or omitting the 'reg-id' parameter. For example, imagine the > >outbound-proxy-set contains two proxies in different domains, > >EP1 and EP2. > > If an outbound-style registration succeeded for a flow > >through EP1, the > >UA might decide to include 'outbound' in its option-tag when > >registering > >with EP2, in order to insure consistency. Similarly, if the > >registration > >through EP1 did not support outbound, the UA might decide to omit the > >'reg-id' parameter when registering with EP2. > > > >I believe the proposed text for D&E is sufficient and should be fairly > >non-controversial. If anyone has any objections, please speak up ASAP > >(and *send text* ;-). > > > >thanks, > >-rohan > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 14:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbm8-00054C-38; Tue, 21 Nov 2006 14:59:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbm7-000546-D0 for sip@ietf.org; Tue, 21 Nov 2006 14:59:23 -0500 Received: from hu-out-0506.google.com ([72.14.214.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmbm6-0002hK-4k for sip@ietf.org; Tue, 21 Nov 2006 14:59:23 -0500 Received: by hu-out-0506.google.com with SMTP id 38so1360251huc for ; Tue, 21 Nov 2006 11:59:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=DSCz+xxsDssg2OMVy4Y2CNF8MmcqdqwUbem7P1e+KbzmF/J/6lz1M2gEjZ/kL5omx3NBQUES9oUpNaYh9Sy8vniyi0TfTAo4wTbYthfqLl3Siff4gf0ZvXN6BDnm/9569YTLaHLl0knhCF3m1rdD2UYnGk7gXs983JG6sWxoxhg= Received: by 10.78.127.2 with SMTP id z2mr6914504huc.1164139160806; Tue, 21 Nov 2006 11:59:20 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 21 Nov 2006 11:59:20 -0800 (PST) Message-ID: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> Date: Tue, 21 Nov 2006 11:59:20 -0800 From: "Rohan Mahy" To: "SIP WG" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] strawman text for FASTEST proposal in outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, To make the discussion about the outbound transport issues more concrete, here is some strawman text for the "FASTEST" direction. thanks, -rohan PROPOSED TEXT: Use of outbound with UDP flows prevents messages larger than 1300 bytes from being delivered using TCP as described in Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP flows in environments where requests are expected to be larger than this size is therefore 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 sip-bounces@ietf.org Tue Nov 21 15:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcBn-0004HL-LC; Tue, 21 Nov 2006 15:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcBl-0004HG-U0 for sip@ietf.org; Tue, 21 Nov 2006 15:25:53 -0500 Received: from mail01.syd.optusnet.com.au ([211.29.132.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmcBh-0007xO-3i for sip@ietf.org; Tue, 21 Nov 2006 15:25:53 -0500 Received: from c210-49-37-63.rochd2.qld.optusnet.com.au (c210-49-37-63.rochd2.qld.optusnet.com.au [210.49.37.63]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kALKPjHa003063 for ; Wed, 22 Nov 2006 07:25:46 +1100 From: Benjamin Carlyle To: sip@ietf.org Content-Type: multipart/mixed; boundary="=-n4GKOEsNBbkdYY6kkC/2" Date: Wed, 22 Nov 2006 06:25:44 +1000 Message-Id: <1164140744.4593.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [Sip] [Fwd: [Sipping] SIP Subscription for SCADA/Stock quotes] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --=-n4GKOEsNBbkdYY6kkC/2 Content-Type: text/plain Content-Transfer-Encoding: 7bit I haven't recieved any responses on the sipping list. Perhaps someone on this list can help clarify my concerns: --=-n4GKOEsNBbkdYY6kkC/2 Content-Disposition: inline Content-Description: Forwarded message - [Sipping] SIP Subscription for SCADA/Stock quotes Content-Type: message/rfc822 Return-Path: Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kAGLbBPp011071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Nov 2006 08:37:15 +1100 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkosE-0000sQ-DO; Thu, 16 Nov 2006 16:34:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkosD-0000sL-4s for sipping@ietf.org; Thu, 16 Nov 2006 16:34:17 -0500 Received: from mail18.syd.optusnet.com.au ([211.29.132.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkos8-00034i-EP for sipping@ietf.org; Thu, 16 Nov 2006 16:34:17 -0500 Received: from c210-49-37-63.rochd2.qld.optusnet.com.au (c210-49-37-63.rochd2.qld.optusnet.com.au [210.49.37.63]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kAGLY8SS002226 for ; Fri, 17 Nov 2006 08:34:10 +1100 From: Benjamin Carlyle To: sipping@ietf.org Content-Type: text/plain Date: Fri, 17 Nov 2006 07:34:05 +1000 Message-Id: <1163712845.4597.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sipping] SIP Subscription for SCADA/Stock quotes X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Content-Transfer-Encoding: 7bit G'day, I work for Westinghouse Rail Systems Australia, and am investigating standard subscription protocols for use in our SCADA product line. SCADA systems (centralised monitoring and control of remote equipment such as power distribution systems) tend to rely a lot on subscription to push data to users and to distributed services. SIP has come up as a possible way to do this, however at present given my reading of rfc3265 I suspect it is not appropriate and would like to confirm with this mailing list. rfc3265 indicates that it is not a general purpose subscription mechanism. Specific weaknesses I see include * There is no obvious way to subscribe to a HTTP resource. Subscriptions are sent to the combination of a SIP url and event package identifier. * Proxies are used for transport through firewall-intensive networks, but do not participate in the subscription. A restful architecture is constrained to support layering, whereby muliple clients who share a proxy might enjoy a multicasting effect through the proxy * Data flow is limited by explicit timers. In a SCADA or stock quote system old data degrades rapidly in value with time, and the objective is to get as close as possible to immediate notifications. The maximum notification rate should be related to available bandwidth, or at worst to network latency * Subscriptions are refreshed individually at a client-specified rate. In a SCADA environment we are likely to have thousands of subscriptions active between a client and server. The client-specified rate may be used as a keep-alive so that the client can detect server death and recreate its subscriptions on another cluster member. I believe it is better for the client to send exactly no renewals. Keep-alive should be sent from the server only, and at a long reliable rate when no data has been transmitted over the subscription during the keep-alive interval. Before I started my quest for an appropriate protocol, I wrote up a strawman which may be viewed here: http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt If I am unable to resolve the issues I have with existing standards I intend to refine and propose the straw-man as a potential standards-track rfc. I hope to find that an appropriate subscription mechanism already exists. I see defining a new one as something of a last resort. Security is still a weakness of my protocol when NOTIFY and PATCHNOTIFY are used. HTTP may only support the EXPIRE notification model without additional trust mechanisms becoming better understood and deployed. I believe I have already ruled out the use of XMPP's XEP-0060 given the way that it makes use of an intermediatary to manage subscriptions but does not summarise subscription data for slow clients: http://mail.jabber.org/pipermail/standards-jig/2006-November/012971.html http://mail.jabber.org/pipermail/standards-jig/2006-November/012974.html http://mail.jabber.org/pipermail/standards-jig/2006-November/013042.html Benjamin. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --=-n4GKOEsNBbkdYY6kkC/2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=-n4GKOEsNBbkdYY6kkC/2-- From sip-bounces@ietf.org Tue Nov 21 15:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcTN-0000dO-1X; Tue, 21 Nov 2006 15:44:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcTL-0000dH-OT for sip@ietf.org; Tue, 21 Nov 2006 15:44:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmcTK-0004aI-Ew for sip@ietf.org; Tue, 21 Nov 2006 15:44:03 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 12:43:59 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kALKhwox027317; Tue, 21 Nov 2006 12:43:58 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kALKhuir006972; Tue, 21 Nov 2006 12:43:58 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:43:56 -0800 Received: from [10.0.33.41] ([10.21.146.29]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:43:56 -0800 In-Reply-To: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A9EF62C-75D0-44A7-828A-C8AB255F01ED@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 21 Nov 2006 15:44:06 -0500 To: SIP X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Nov 2006 20:43:56.0501 (UTC) FILETIME=[C3928050:01C70DAD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1047; t=1164141838; x=1165005838; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20strawman=20text=20for=20FASTEST=20proposal=20in=20out bound |Sender:=20; bh=xVjSd6/+gqHarmfoo82AjJmdLbCyNcBQTqQUN9bfxsQ=; b=yzKsua/K6k5kT4H4LtMTxRyxDaIFSJwysCSo5EZNUI3jH45TP/p3RqfT/LmQJ+e4NNDlbNtd OnXsjZtH1r3z/PMTesDfxPG+ZgIRJmXnIeSqYnGubCuqA587TrSafJQU; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Rohan Mahy Subject: [Sip] Re: strawman text for FASTEST proposal in outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just wanted to point out that at everyone of the recent IETF meetings Rohan and I have gotten strong feedback from the WG that they want this done soon so I feel pretty strongly we should be on the route Rohan described as "Fastest". Some of the comments for alternatives from this I think I would argue with but that is probably not very relevant if people feel they can live with the text below and just get outbound finished. Cullen On Nov 21, 2006, at 2:59 PM, Rohan Mahy wrote: > Hi, > > To make the discussion about the outbound transport issues more > concrete, here is some strawman text for the "FASTEST" direction. > > thanks, > -rohan > > PROPOSED TEXT: > Use of outbound with UDP flows prevents messages larger than 1300 > bytes from being delivered using TCP as described in Section 18.1.1 > RFC 3261. Use of outbound in conjunction with UDP flows in > environments where requests are expected to be larger than this size > is therefore 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 sip-bounces@ietf.org Tue Nov 21 16:06:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmco0-0000Tz-AC; Tue, 21 Nov 2006 16:05:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcny-0000TV-9h for sip@ietf.org; Tue, 21 Nov 2006 16:05:22 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gmcns-00031C-Rj for sip@ietf.org; Tue, 21 Nov 2006 16:05:22 -0500 Received: (qmail invoked by alias); 21 Nov 2006 21:05:14 -0000 Received: from p549866D1.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.102.209] by mail.gmx.net (mp018) with SMTP; 21 Nov 2006 22:05:14 +0100 X-Authenticated: #29516787 Message-ID: <45636A0D.2040900@gmx.net> Date: Tue, 21 Nov 2006 22:05:17 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Rosen References: <01dd01c70d71$dec7a580$640fa8c0@cis.neustar.com> In-Reply-To: <01dd01c70d71$dec7a580$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 Cc: 'IETF SIP List' , 'GEOPRIV' Subject: [Sip] Re: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, thanks for the quick response. Please find my comments inline: Brian Rosen wrote: > Thanks for your detailed review comments. My views are inline. > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, November 21, 2006 6:06 AM >> To: IETF SIP List; GEOPRIV >> Subject: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance- >> 05.txt >> >> Hi Brian, >> Hi James, >> >> I have reviewed the document. >> >> First, I would like to thank you for improving the document. But, I >> still have a few comments: >> >> Questions: >> >> >> You write: >> " >> >> A dereference of a location-by-reference URI using SUBSCRIBE is not >> violating a PIDF-LO 'retransmission-allowed' element value set to >> 'no', as the NOTIFY is the only message in this multi-message series >> of transactions that contains the UAC's location, with the location >> recipient being the only SIP element to receive location - which the >> purpose of this extension: to convey location to a specific >> destination. >> " >> >> I wasn't quite sure what you are about to say with this statement. If the >> >> Location Recipient receives a reference and it resolves it then you are >> >> saying that this is OK even if the retransmission-allowed flag says "no". >> >> Correct? > Yes, correct. In fact if 3 proxies on the path sequentially resolve the > reference when retransmission-allowed='no' that is okay. However, none of > those proxies may retransmit the location. I see. I think it would be good to exactly add this example. > >> >> Technical Aspects: >> >> * Proxy Usage >> >> When a proxy adds a reference to a PIDF-LO then a number of issues remain >> >> unclear (as discussed throughout the Geopriv work), namely: >> >> - What does the PIDF-LO contain that is created by the SIP proxy? > First of all, you are making an assumption that the proxy creates the value > returned by the reference it adds. That is not likely the case. It's more > likely that the proxy has access to a LIS which supplies it the reference to > include. > > I think the reference resolves to the same PIDF-LO that the LIS would have > given the endpoint. If indeed the proxy actually is the dereference agent, > then it would return a PIDF-LO that would look exactly like a LIS would > provide. I'm expecting such a PIDF-LO would have very few of the fields > defined in PIDF. For example, a "Contact" is unlikely to be present. Most > importantly, I think the proxy, like the LIS, has to include a ruleset that > conforms to the preferences of the target. > > I'm not sure that there needs to be any text in conveyance that says that. In some sense it refers to the discussion we have in the Geopriv L7 LCP work. An approach of requesting a reference to a PIDF-LO from the LIS by the end host, then adding the reference to a SIP message compared to the approach of a LIS providing the reference to a proxy that then adds then the reference sounds somewhat similar except that the latter one is more complicated since the end user is not involved at all which limits the user's ability to influence something. After the discussions we had in the past and the challenges we investigated I essentially see only one reasonable option: Copy-and-paste the text from Section 6 of http://tools.ietf.org/wg/geopriv/draft-schulzrinne-geopriv-locationref-00.txt I think that everything else is a huge privacy problem. >> >> * How does the proxy know that location information has to be added? >> >> - There is a privacy problem if the SIP proxy acts without explicit >> >> indication that location information is added. > The use case we know about is the emergency case, where location is not > provided by the endpoint and the proxy knows where the endpoint is. The > only circumstance that is likely to be true is where the SIP network and the > access network are the same domain, or they have pre-established > relationship, and a way of correlating identifiers such that the SIP network > can get the correct location (or reference). > > Here, perhaps we need text that explains this. I had expected this would > appear in ecrit-framework, but I'm not sure now that it's a good idea to > limit proxy add of location to the emergency case. > > I do think we get into pretty serious sticky wickets with what we can say > for the non-emergency case. I would expect we have to say that the proxy > has explicit permission, and a ruleset by the target for the location it is > adding, but that doesn't really express the wishes of the target of WHEN it > is okay to add location. I was actually referring only to the case where the proxy uses some information to conclude that location information has to be added. I see only two ways to get this accomplished in a way that there is not a huge privacy problem: a) Applicability statement to focus on the emergency service case only. There, the emergency service identifier (or in some cases the emergency service number) can help to determine the context. Does not work in the general case. b) SIP UAC attaches a context tag to the SIP signaling message to indicate the context. We came up with this idea in SIP SAML since we had a similar problem there when it comes to determining the context. See issue#4: http://www.tschofenig.priv.at:8080/saml-sip/issue4 > >> >> * Using Protocol >> >> You write: >> " >> Other protocols used in the Location URI MUST be reviewed against >> the RFC3693 criteria for a using protocol. >> " >> >> Later, in Section 3.6 you write: >> " >> Use of other protocols for dereferencing >> of a pres: URI is not defined, and such use is subject to review >> against RFC3693 using protocol criteria. >> " >> >> I disagree that the protocol used to resolve the reference has to be a >> using >> >> protocol. Hence, I suggest to delete this sentence. > Well, perhaps this should be discussed in the LbyR design team. Certainly, > the location value is carried in the protocol. I don't understand how it > could not be viewed as a using protocol. In our past discussions I saw two aspects: a) SIP is per-se accepted as a using protocol. b) HTTP is per-default not accepted as using protocol. For (a): The proxy server/LIS is not the same as the LS/Presence Server in my view. Please see the recent discussion on this topic (pointing to terminology). For (b): I know no fundamental problem to get HTTP to perform a dereferencing step from a reference to an LO. As such, in order to be sensible to the past discussions I would appreciate if the strange RFC 3693 terminology is not stressed too much in this document based on what we already know after the long, long discussions we had. It is not an important and major change though. > >> >> * Privacy Rules >> >> You write: >> " >> Entities receiving location information MUST honor the usage element >> rules per RFC4119. Such entities MUST NOT alter the rule set. >> " >> >> The last sentence is not correct. Let me give you an example: A SIP UAC >> >> obtains location information from GPS and uses a PUBLISH to upload the >> >> PIDF-LO to the Location Server/ Presense Server. This server has rules >> that >> >> control access to location information. As part of these rules the content >> >> of the Location Object including the rules might be modified. > While I can imagine a way to express a rule that modifies the ruleset, I > don't think we have ever discussed that kind of rule. If we allow such > things that we need some pretty convoluted language. If you want such a > capability, then please propose wording that permits a rule to modify a rule > set, but doesn't allow an arbitrary modification of the ruleset and show me > some other place where we have used that language. This has to be the same > as, for example, presence. Hmmm. Please find the already specified the rules in Section 8 of http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-08.txt I am not referring to a new thing. I think everything is correct if you delete the following sentence: "Such entities MUST NOT alter the rule set.". > >> >> * The examples pick unfortunate references >> (sips:server5.atlanta.example.com/alice123) >> that give me the impression that the reference contains the user identity. >> The document clearly needs to point out that this is not the case. The > I think this is a good point and we should modify the example text. OK. > >> document also does not indicate >> >> that the reference is only kept for a certain period of time (soft-state). >> The document does not even mention security aspects when retrieving the >> >> reference. > The notion of a time limited reference is specific to the scheme. It was > proposed in Henning (et al)'s SIP based LCP for example, but not in all LbyR > mechanisms. I don't know if -conveyance is the right place to discuss that > issue. > > We don't have any mechanism that discusses how long any element should keep > a reference, regardless of whether the dereference mechanism has an > expiration. Another LbyR design team topic? > > I'd prefer that -conveyance not be the place that defines such things. > But how long should the LIS/Proxy Server keep the reference? You cannot expect the reference to stay there for ever. You can always say that " The reference that is added by the Proxy is keep for an unspecified period of time. The Location Recipient that performs the dereferencing step should not make any assumption about the ability to resolve the reference. The reference creating entity might at any point in time decide to destroy the reference as part of a garbage collection process. It is RECOMMENDED that the reference that points to the Location Object is stored for at least 2 minutes. " I think we need to state something. I know that it is not perfect. We do, however, also want to let people realize that a proxy doing some actions on behalf of the SIP UAC is not an ideal solution and suffers from a number of problems. >> >> * Security in Section 5 SIP Element Behavior >> >> I am confused with the text in Section 5. What MUST and what SHOULD be >> used >> >> when protecting a location-by-value and a location-by-reference? >> >> SHOULD for TLS usage with location-by-value and location-by-reference. > Yeah, we should clean up the language here. I think both. Here is my suggestion: * Non-Emergency Based Scenarios If the location-based routing has to be performed then TLS is MUST. S/MIME is not possible. For the other case S/MIME is a SHOULD. SHOULD only because it is difficult to use. * Emergency Based Scenarios SHOULD for TLS; fall-back to non-security version if TLS does not work S/MIME non possible. > >> No statement about usage of S/MIME. > Right. Need some text that S/MIME SHOULD be used to protect a value or > reference if the intention is that the only element that should get it is > the opposite UA. I agree that the location by reference / location by value case should not be treated differently with respect to this security issue. > >> I wonder why self-signed certificates shouldn't be used as stated with: >> " >> Self-signed certificates SHOULD NOT be used for protecting PIDF, >> as the sender does not have a secure identity of the recipient. >> " >> For encryption (and that's what we are talking about here) it heavily >> >> depends on the way how the self-signed certificate was obtained. I might >> >> share my certificate with you and hence that's an extemely useful way todo >> >> compared to the usage of TLS in a hop-by-hop way where a number of >> entities >> >> see my location along the path. > Perhaps you would send some text to cover this case. I tried a couple of > ways and didn't think my attempts made any sense. Ok. I can try something. > >> Identity info in the PIDF. In previous discussion I was wondering and >> asking >> >> the Geopriv group whether there is some semantic associated with the >> >> identity in the PIDF. If there is, then you cannot put anything you like >> >> into the PIDF. If there isn't then why should we ever want to put >> something >> >> meaningful in there since it greatly impacts the privacy risks. > I don't understand this. If it's LbyV and the endpoint puts it in, then it > controls the identity, and it CAN put anything it wants to. That's true. The LbyV case for the end point is easy. > > In a case of LbyR, then the LIS, or whomever is constructing the PIDF needs > a mechanism to allow the target to specify a ruleset, and probably needs to > allow it to specify the identity as well. But this only works if the end host is allowed to interact with the LIS when putting anything meaningful in there. This, however, depends on the outcome of the Geopriv L7 work. I would argue that this is outside the scope of this document (for good reasons) For the case where the proxy adds the reference I see the need to put a randomized identity in there, if it does not harm. In scope. I think it would be useful to distinguish these cases. > >> I see a problem with retargeting and forking where the Location >> Recipient is actually not know ahead of time and S/MIME usage is >> actually not really feasible. Would some guidance be useful? > Not sure I know what you mean. I've long considered the problem that the > hop by hop mechanism allows any proxy on the path to see location, but it > also allows the opposite UA to see it. There isn't a way to say "I trust > the proxies, but I don't trust the endpoint". On the other hand, > retarget/fork may be precisely the reason S/MIME can't be used, and TLS is > very appropriate. Ideally, it would be great to use S/MIME to allow true protection of location information (Additional remark: If location-based routing by proxies is not used; again, if the end point determines the ultimate target then it does not need to consult proxies todo so.). Now, the problem we see to in various places is that due to retargeting and forking even the idea of S/MIME usage is not only difficult (due to the lack of the deployed certs) but also due to technical issues. This is not particularly good. I see only one solution: Don't sent location with the initial message. Wait until you see to whom you are talking to. Send location later. Is this something that could work? > > I do think at least mentioning the issue here is warranted. I don't see > need for more mechanism. > >> * Section 7. >> >> The document refers to 'using protocols' for both the UAC <-> UAS and to >> the dereferencing protocol. I assume that Section 7 only addresses the >> UAC <-> UAS communication. Since I am in favor of not treating the >> derefencing protocol a 'using protocol' I am fine with it. >> >> Actually, I would prefer to move Section 7 into the appendix since this >> is just such an artifical story that it makes me nervous. It is not your >> fault; it is just the way how RFC 3693 was written. > See above; I fail to see how the dereference can possibly avoid being a > using protocol. See my response above. Regardless of the using protocol discussion I don't think that Section 7 is too valuable. For example, why is 'Single Message Transfer' anything useful from a privacy or security point of view? Well, maybe I got a bit frustrated on this topic... > >> * The security consideration section isn't particularly good. If I have >> time I rewrite it. > Suggestions are welcome. Send text, or at least talking points. I will try todo something. > >> >> >> Editorial Aspects: >> >> The term 'Location' is written with a capital letter (see for example >> first >> >> paragraph in Section 1) whereas other RFC3693 terms that are meant to be >> >> written with a capital letter aren't (example: 'target', 'location >> object', >> >> 'using protocol', 'location recipient'). I suggest to stick with RFC3693. > Good point. We'll fix this. > >> >> " >> This document describes how Location can be "conveyed" (that is, >> sent on the Internet) from a SIP user agent, or in some >> circumstances a proxy server acting on behalf of a user agent, to >> another entity using the SIP [RFC3261] protocol. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> " >> >> Either write using SIP [..] or using the Session Initiation Protocol >> [...]. > Okay > >> >> I suggest to rewrite the following paragraph from: >> >> " >> As recited in RFC3693, location often must be kept private. The >> location object (PIDF-LO) contains rules which are binding on the >> location recipient and controls onward distribution and retention of >> the location. This document describes the security and privacy >> considerations that must be applied to location conveyed with SIP. >> >> " >> >> to: >> >> " >> The >> Location Object contains rules which provide guidance for the Location >> >> Recipient on the onward distribution and retention of >> the received location information. This document describes the >> security >> >> and privacy >> considerations that must be applied to location conveyed with SIP. >> " > I don't understand your objection to the text as written. Are you objecting > to the reference to 3693, the explicit mention of PIDF-LO, the word > "binding" or something else? The reason why I suggest the change is that we provide two ways to keep location private: First, we offer access control solutions using policies. Second, we attach rules as hints how to treat location info. I think I rephrased it in such a way that it focuses on the second aspect by removing 'location often must be kept private.'. If you keep this sentence in there then you also need to talk about the access control aspect. I also had problems with the term 'binding' since I didn't quite understand what it means. > >> >> I don't know what this sentence should mean in Section 1 at this part of >> the >> >> section. >> " >> Often, location is sent from the User Agent Client to the User Agent >> Server, or vice versa for purposes that are beyond the scope of this >> document. >> " >> >> There seems to be a copy-and-paste problem. > We'll look at it > >> >> You write: >> >> " >> The Geolocation header is introduced to signify that location is >> included in a SIP message to provide either a content identifier >> (cid:) pointer to the body part containing the UAs PIDF-LO, or a >> location-by-reference URI that may subsequently be "dereferenced" by >> a using protocol (which may be SIP or another protocol). >> " >> >> Please delete the following part " by >> a using protocol (which may be SIP or another protocol)" since we >> haven't >> >> concluded in our discussion that the dereferencing protocol is indeed a >> >> using protocol. > See above > >> Actually, I think that the entire paragraph is not particularly useful in >> >> the introduction and the subsequent paragraph fits much better to the >> >> previous one. >> >> >> You write: >> " >> The Geolocation header MUST contain one two types of URIs: >> ^^^^^^^^^^^^ >> one of two types >> " > OK > >> >> The example contains a company name >> >> (www.cisco.com) although it should, >> >> according to the guidelines something like "www.example.com". > OK > >> >> Section 4.3 uses the term 'LIS' and does not mention what it is. >> Just avoid it. > Hmmm. We really do have to agree on terminology, no question. The notion > that LIS is not acceptable is very disconcerting. Outside of IETF, LIS is a > well understood term. Location Generator is not. Hmm. What should we do? > >> >> IDNITS: >> >> Experimental warnings: >> - Missing Reference: 'RFC3851' is mentioned on line 343, but not >> defined >> 'resulting resolution, per [RFC3851], resolves to a sip: or sips:...' >> >> - Unused Reference: 'ID-Loc-Reg' is defined on line 891, but not >> >> referenced >> '[ID-Loc-Reg]...' > Will fix > >> >> Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: >> - It seems as if not all pages are separated by form feeds - found 0 >> form >> feeds but 26 pages > Hmmm, tool problem. James uses the Word template. Don't use the word template. Use XML to RFC. > >> >> tmp/draft-ietf-sip-location-conveyance-05.txt(294): Line has weird >> spacing: >> >> '... Rr ar ...' >> tmp/draft-ietf-sip-location-conveyance-05.txt(298): Line has weird >> spacing: >> >> '... Rr ar ...' > OK > Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 16:39:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdKn-0004sj-R6; Tue, 21 Nov 2006 16:39:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdKl-0004rw-SY for sip@ietf.org; Tue, 21 Nov 2006 16:39:15 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GmdKi-000274-Ic for sip@ietf.org; Tue, 21 Nov 2006 16:39:13 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kALLd4g10656; Tue, 21 Nov 2006 16:39:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Date: Tue, 21 Nov 2006 15:39:03 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> In-Reply-To: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] strawman text for FASTEST proposal in outbound thread-index: AccNp+BsIQvvo0ujQyirswDktAFF+QADVzgw From: "Francois Audet" To: "Rohan Mahy" , "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > To make the discussion about the outbound transport issues=20 > more concrete, here is some strawman text for the "FASTEST" direction. >=20 > thanks, > -rohan >=20 > PROPOSED TEXT: > Use of outbound with UDP flows prevents messages larger than=20 > 1300 bytes from being delivered using TCP as described in=20 ^^^ Shouldn't this say "UDP"? > Section 18.1.1 RFC 3261. Use of outbound in conjunction with=20 > UDP flows in environments where requests are expected to be=20 > larger than this size is therefore NOT RECOMMENDED. But otherwise, looks good.=20 Like Cullen, I do agree with the FASTEST direction. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 18:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmf3a-0002by-Rj; Tue, 21 Nov 2006 18:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmf3Z-0002bi-CF for sip@ietf.org; Tue, 21 Nov 2006 18:29:37 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmf3Y-0004Fb-3A for sip@ietf.org; Tue, 21 Nov 2006 18:29:37 -0500 Received: from [10.10.16.240] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kALMX2TO020727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Nov 2006 16:33:02 -0600 In-Reply-To: <1164029015.7482.23.camel@macbuster.research.nokia.com> References: <7374777208BDC7449D5620EF942325676E7C67@esealmw113.eemea.ericsson.se> <1164029015.7482.23.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 21 Nov 2006 17:29:02 -0600 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" , "ext Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 20, 2006, at 7:23 AM, Aki Niemi wrote: > > But unless someone can clearly explain where and how TCP fails to work > in a show-stopper manner, such claims are hogwash, and we should just > bite the bullet and make sip-outbound TCP-only. > The arguments against TCP are, if I understand them correctly: 1) TCP may be harder to implement on high fan-out servers because naive systems using the socket library run out of sockets fairly quickly. Response: So? Either learn to program using poll/select, or build smaller proxies. 2) TCP may cause the consumption of more resources in the mobile radio networks (specifically the battery) because of all those retransmissions and keepalives. Response: Of course, outbound with UDP doesn't fare much better in this case, as we're still doing keepalives, and TCP's keepalives can be turned down or off anyhow. 3) TCP is less desirable for mobile use because each proxy attachment requires three more packets (the TCP handshake), and the extra two seconds this might require at startup on a slow GPRS link is a show stopper. Response: Big fat hairy deal. 4) TCP's session binding makes it harder to do a distributed proxy cluster where SIP state is distributed across the cluster but TCP state isn't. Response: Outbound of course helps with this by giving us the option to have multiple explicit entry points into the cluster. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 18:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfGm-0004QX-DP; Tue, 21 Nov 2006 18:43:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfGk-0004Lb-HS for sip@ietf.org; Tue, 21 Nov 2006 18:43:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmfGi-0006Jt-7H for sip@ietf.org; Tue, 21 Nov 2006 18:43:14 -0500 Received: from [10.10.16.240] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kALMksqc020803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Nov 2006 16:46:54 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Date: Tue, 21 Nov 2006 17:42:54 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 21, 2006, at 3:39 PM, Francois Audet wrote: >> PROPOSED TEXT: >> Use of outbound with UDP flows prevents messages larger than >> 1300 bytes from being delivered using TCP as described in > ^^^ > Shouldn't this say "UDP"? > Normally, if one were not able to deliver a response using UDP due to the size of that response, one might establish a TCP connection to deliver that response. But unless you do something tricky when using outbound to cross a NAT (like have a pre-established TCP connection), you can't just "fall back" to TCP for responses from "outbound proxy" to UA, because you'd be in a position of trying to initialize a TCP connection going the "wrong way" through a NAT. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 19:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmfm5-0005K5-KG; Tue, 21 Nov 2006 19:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmfm4-0005Jv-BA for sip@ietf.org; Tue, 21 Nov 2006 19:15:36 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmfm3-0001wK-25 for sip@ietf.org; Tue, 21 Nov 2006 19:15:36 -0500 Received: by ug-out-1314.google.com with SMTP id 72so25627ugd for ; Tue, 21 Nov 2006 16:15:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nan9duyrMz+W2eY+FeYAj0ViKa5uoaZBeKRnxRD/6vZANxX+1rfbvM86ASeRv9eALpGjxzIpjtkP5FEOv+6NqEbqgPrW6V3Gcgix6wFGx8c3X7t5SuLtk/S4n+20iW+cAVZ6M59KFf0Oy97eJD+F46UvbCyABWmTNkKEisANdTs= Received: by 10.78.81.20 with SMTP id e20mr7158654hub.1164154533798; Tue, 21 Nov 2006 16:15:33 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 21 Nov 2006 16:15:32 -0800 (PST) Message-ID: <953beacc0611211615g552f8847v6ec745749e741353@mail.gmail.com> Date: Tue, 21 Nov 2006 16:15:32 -0800 From: "Rohan Mahy" To: "Francois Audet" Subject: Re: [Sip] strawman text for FASTEST proposal in outbound In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois, On 11/21/06, Francois Audet wrote: > > > To make the discussion about the outbound transport issues > > more concrete, here is some strawman text for the "FASTEST" direction. > > > > thanks, > > -rohan > > > > PROPOSED TEXT: > > Use of outbound with UDP flows prevents messages larger than > > 1300 bytes from being delivered using TCP as described in > ^^^ > Shouldn't this say "UDP"? No. Outbound using UDP flows prevents the switchover to a congestion-controlled transport, such as TCP as described in this quote from RFC 3261: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [36] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. I think we've already established that if a UA was going to bother establishing a TCP or TLS flow that there would be no benefit to using a UDP flow. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 19:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmflU-0005I9-LD; Tue, 21 Nov 2006 19:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmflS-0005I2-F5 for sip@ietf.org; Tue, 21 Nov 2006 19:14:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmflP-0001u8-4d for sip@ietf.org; Tue, 21 Nov 2006 19:14:58 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 16:14:54 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAM0EsmM009606; Tue, 21 Nov 2006 16:14:54 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAM0Esip000415; Tue, 21 Nov 2006 16:14:54 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 16:14:54 -0800 Received: from [192.168.0.102] ([10.21.145.167]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 16:14:53 -0800 Message-ID: <45639684.2090600@cisco.com> Date: Tue, 21 Nov 2006 16:15:00 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] strawman text for FASTEST proposal in outbound References: <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2006 00:14:53.0957 (UTC) FILETIME=[3C010350:01C70DCB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1384; t=1164154494; x=1165018494; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20strawman=20text=20for=20FASTEST=20proposal=20 in=20outbound |Sender:=20; bh=486fcbdtrE6Z6NnMfl6Zg662OquGPQp1LSGAjlYs8kI=; b=Ay+avaL8zxMMwkPQwvDYjEfcXWL363+GrblmKnmk9Bf2LNrv9D1zKwLzDnViPFToKWKPTVk6 8KWVkHAMC0B1L6MfU3C8FbO+fOgULp9BLEQqyqZD0CvWQQm2f9fPgEmD; Authentication-Results: sj-dkim-1; header.From=mat@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP WG , Cullen Jennings , Francois Audet , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 21, 2006, at 3:39 PM, Francois Audet wrote: >>> PROPOSED TEXT: >>> Use of outbound with UDP flows prevents messages larger than >>> 1300 bytes from being delivered using TCP as described in >> ^^^ >> Shouldn't this say "UDP"? >> > > Normally, if one were not able to deliver a response using UDP due to > the size of that response, one might establish a TCP connection to > deliver that response. > > But unless you do something tricky when using outbound to cross a NAT > (like have a pre-established TCP connection), you can't just "fall > back" to TCP for responses from "outbound proxy" to UA, because you'd > be in a position of trying to initialize a TCP connection going the > "wrong way" through a NAT. Right... the thing that struck me about this is that there seems to be an implicit assumption that deployments can "know" how things will be used. It seems to me that you "know" these things for about as long as it takes for the assumption to broken and then you're really hosed. Considering that SIP is not entirely unlike a trash barge hauling stuff out to the New Jersey outer banks, I'm not very convinced that the barge isn't going to repeatedly sink unless there's explicit fallback for those inevitable heavy loads. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 19:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfxE-0005fe-Dc; Tue, 21 Nov 2006 19:27:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfxD-0005fQ-Fd for sip@ietf.org; Tue, 21 Nov 2006 19:27:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmfxC-0003Bj-6I for sip@ietf.org; Tue, 21 Nov 2006 19:27:07 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2006 16:27:05 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kAM0R5mk016275; Tue, 21 Nov 2006 16:27:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAM0QsOZ029144; Tue, 21 Nov 2006 16:27:01 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 16:26:56 -0800 Received: from [192.168.0.102] ([10.21.145.167]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 16:26:56 -0800 Message-ID: <45639957.60903@cisco.com> Date: Tue, 21 Nov 2006 16:27:03 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] strawman text for FASTEST proposal in outbound References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> <953beacc0611211615g552f8847v6ec745749e741353@mail.gmail.com> In-Reply-To: <953beacc0611211615g552f8847v6ec745749e741353@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2006 00:26:56.0599 (UTC) FILETIME=[EABB6E70:01C70DCC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=376; t=1164155225; x=1165019225; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20strawman=20text=20for=20FASTEST=20proposal=20 in=20outbound |Sender:=20; bh=ehjHn+V3cDhNvb63ZkxBQ/L98TwlJy7WtA8LbR/m4M4=; b=pzzdp3ZRJLcUJL8aoa7MalM9pLjgC9LhMoBsfM9CP6JcByw/UbO0FiSNAvS1N7wIXZ3VrJw5 GJau2cFWwJKqmm7ji8fnMUYusYtTq1pTWYaZDJXUvqsbUndsLI2qYAaU; Authentication-Results: sj-dkim-8; header.From=mat@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: SIP WG , Cullen Jennings , Francois Audet , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > I think we've already established that if a UA was going to bother > establishing a TCP or TLS flow that there would be no benefit to using > a UDP flow. Does there exist any plausible scenario where that won't be the case? Let's take into consideration that the time horizon here should be viewed in the decades rather than in the months. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 20:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmghk-0000mX-LV; Tue, 21 Nov 2006 20:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmghi-0000mQ-VO for sip@ietf.org; Tue, 21 Nov 2006 20:15:10 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmghh-00033a-ML for sip@ietf.org; Tue, 21 Nov 2006 20:15:10 -0500 Received: by ug-out-1314.google.com with SMTP id 72so34906ugd for ; Tue, 21 Nov 2006 17:15:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nuo5qHUvICUqLN4OiWZUFcNhFl5afmolBBR7e1lVf/0bqk2KCD6ZN/my5q1bjVG3BuKqYk07TY79TmHtn9l27Cp86GHy35/vJTTMWQMY3twAgfOC+QadyiJol45xcHnzA20IU0bG7Xwg0btquDJNfmULO2ZdIZ1wvdeaJpHp7JE= Received: by 10.78.185.7 with SMTP id i7mr7176572huf.1164158108374; Tue, 21 Nov 2006 17:15:08 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 21 Nov 2006 17:15:08 -0800 (PST) Message-ID: <953beacc0611211715o72738782ua974a41ecd07132@mail.gmail.com> Date: Tue, 21 Nov 2006 17:15:08 -0800 From: "Rohan Mahy" To: "Francois Audet" Subject: Re: [Sip] strawman text for FASTEST proposal in outbound In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois, On 11/21/06, Francois Audet wrote: > > > To make the discussion about the outbound transport issues > > more concrete, here is some strawman text for the "FASTEST" direction. > > > > thanks, > > -rohan > > > > PROPOSED TEXT: > > Use of outbound with UDP flows prevents messages larger than > > 1300 bytes from being delivered using TCP as described in > ^^^ > Shouldn't this say "UDP"? No. Outbound using UDP flows prevents the switchover to a congestion-controlled transport, such as TCP as described in this quote from RFC 3261: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [36] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 21:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmhx4-0005uP-Ia; Tue, 21 Nov 2006 21:35:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmhx3-0005uF-DQ for sip@ietf.org; Tue, 21 Nov 2006 21:35:05 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmhx0-0007ba-6g for sip@ietf.org; Tue, 21 Nov 2006 21:35:05 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (sccrmhc13) with SMTP id <2006112202350101300atr2qe>; Wed, 22 Nov 2006 02:35:01 +0000 Message-ID: <096401c70dde$6735fa40$6a01a8c0@china.huawei.com> From: "Spencer Dawkins" To: "SIP WG" References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Date: Tue, 21 Nov 2006 20:32:05 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Rohan, > Hi, > > To make the discussion about the outbound transport issues more > concrete, here is some strawman text for the "FASTEST" direction. > > thanks, > -rohan > > PROPOSED TEXT: > Use of outbound with UDP flows prevents messages larger than 1300 > bytes from being delivered using TCP as described in Section 18.1.1 > RFC 3261. Use of outbound in conjunction with UDP flows in > environments where requests are expected to be larger than this size > is therefore NOT RECOMMENDED. I like this, but it seems to be confusing. Perhaps "Use of outbound with UDP flows prevents fallback to TCP for messages larger than 1300 bytes as described in ..." Since you are giving guidance anyway, is it possible (and non-contentious) to provide a little more help to people who are trying to connect the dots? "... NOT RECOMMENDED. Environments where large requests are likely to occur include ..." I guess my concern is that NOT RECOMMENDED is roughly a SHOULD NOT, so the reader is responsible for figuring out whether the problem will occur or not. Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 21 23:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjKi-0001tI-OA; Tue, 21 Nov 2006 23:03:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjKh-0001t4-Ev for sip@ietf.org; Tue, 21 Nov 2006 23:03:35 -0500 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmjKf-0002EP-3q for sip@ietf.org; Tue, 21 Nov 2006 23:03:35 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20061122040327m1500aqk12e>; Wed, 22 Nov 2006 04:03:32 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAM43Q5K009975 for ; Tue, 21 Nov 2006 23:03:26 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAM43QrX009971; Tue, 21 Nov 2006 23:03:26 -0500 Date: Tue, 21 Nov 2006 23:03:26 -0500 Message-Id: <200611220403.kAM43QrX009971@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1164140744.4593.1.camel@localhost.localdomain> (benjamincarlyle@optusnet.com.au) Subject: Re: [Sip] [Fwd: [Sipping] SIP Subscription for SCADA/Stock quotes] References: <1164140744.4593.1.camel@localhost.localdomain> X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Benjamin Carlyle --=-n4GKOEsNBbkdYY6kkC/2 Content-Disposition: inline [45 lines deleted] Perhaps you could trim out the 47 lines of redundant headers? rfc3265 indicates that it is not a general purpose subscription mechanism. Specific weaknesses I see include * There is no obvious way to subscribe to a HTTP resource. Subscriptions are sent to the combination of a SIP url and event package identifier. Why is this a "weakness", since RFC 3265 is *intended* as a SIP-specific subscription mechanism? * Proxies are used for transport through firewall-intensive networks, but do not participate in the subscription. A restful architecture is constrained to support layering, whereby muliple clients who share a proxy might enjoy a multicasting effect through the proxy A proxy *by definition* doesn't participate in any of the transactions it forwards. But you could define an appropriate agent that would forward data to multiple supplies. BTW, what is a "restful" architecture? And what do you mean by "layering"? * Data flow is limited by explicit timers. In a SCADA or stock quote system old data degrades rapidly in value with time, and the objective is to get as close as possible to immediate notifications. The maximum notification rate should be related to available bandwidth, or at worst to network latency RFC 3265 does not specify any timers for rate-limiting of subscription notifications, and most implementations do not do much rate-limiting.. * Subscriptions are refreshed individually at a client-specified rate. In a SCADA environment we are likely to have thousands of subscriptions active between a client and server. It seems like you might want to bundle those subscriptions into a single subscription, if you are using the RFC 3265 model. Maintaining thousands of *anything* in a protocol usually indicates an opportunity for optimization. The client-specified rate may be used as a keep-alive so that the client can detect server death and recreate its subscriptions on another cluster member. I believe it is better for the client to send exactly no renewals. In RFC 3265, subscription refresh is used so that the server can detect client death. I suspect that any other subscription protocol will need a similar mechanism. If I am unable to resolve the issues I have with existing standards I intend to refine and propose the straw-man as a potential standards-track rfc. Do you have any reason to believe that there are others out there who would like to interoperate using a new mechanism? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From staffordaudrie@cosentiniconstruction.com Wed Nov 22 01:19:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmlSN-0007Ts-1l for sip-archive@lists.ietf.org; Wed, 22 Nov 2006 01:19:39 -0500 Received: from [87.119.102.230] (helo=cbjjk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmlSK-0007uK-TV for sip-archive@lists.ietf.org; Wed, 22 Nov 2006 01:19:39 -0500 Message-ID: <009601c70df7.6b33f980.b360c0a8@lanie> Date: Wed, 22 Nov 2006 05:31:11 +0000 From: gert sayre User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: prescott audrye Subject: Free vacation Content-Type: multipart/alternative; boundary="---------0000007F.01C70DF7" X-Spam-Score: 4.9 (++++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. -----------0000007F.01C70DF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are currently accepting applications for Guarantee Manager Position. REQUIREMENTS: Candidate must have experience with UPS and FedEx shipments, stable internet connection at home. Computer Literate a must Ideal candidates will need to fill requisitions and orders in a timely manner, ability to lift up to 50 pounds. We offer excellent compensation, benefits and opportunities for personal growth, flexible hours, training and development, as well as the vacation schedule. Great opportunity to work in a fast paced environment and learn from a world-class organization. JOIN A WINNING TEAM! If you are looking for a competitive wage, solid opportunity and a career path to success, contact us now! We would LOVE to work with you, so reply to this posting and send us your resume today. Don't put your career in the hands of just anyone, put it in the hands of a specialist. Join the Shark Logistics Staffing team! Send your resumes: rick@shark-log.com (Only U.S. resumes accepted) Do you have additional questions? Don't hesitate to contact us! -----------0000007F.01C70DF7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
We are currently accepting applications for Guarantee Manager Position.

REQUIREMENTS:
Candidate must have experience with UPS and FedEx shipments, stable internet connection at home. Computer Literate a must Ideal candidates will need to fill requisitions and orders in a timely manner, ability to lift up to 50 pounds.

We offer excellent compensation, benefits and opportunities for personal growth, flexible hours, training and development, as well as the vacation schedule. Great opportunity to work in a fast paced environment and learn from a world-class organization.

JOIN A WINNING TEAM!
If you are looking for a competitive wage, solid opportunity and a career path to success, contact us now! We would LOVE to work with you, so reply to this posting and send us your resume today. Don't put your career in the hands of just anyone, put it in the hands of a specialist. Join the Shark Logistics Staffing team!

Send your resumes: rick@shark-log.com (Only U.S. resumes accepted)
Do you have additional questions? Don't hesitate to contact us!
-----------0000007F.01C70DF7-- From sip-bounces@ietf.org Wed Nov 22 02:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmmnF-0007Rw-83; Wed, 22 Nov 2006 02:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmmnE-0007Q9-5z for sip@ietf.org; Wed, 22 Nov 2006 02:45:16 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmmnC-0005tl-IO for sip@ietf.org; Wed, 22 Nov 2006 02:45:16 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAM7hXES026183; Wed, 22 Nov 2006 09:45:05 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:44:45 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:44:44 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound open issues from IETF 67 Date: Wed, 22 Nov 2006 09:44:43 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03060ECE@esebe103.NOE.Nokia.com> In-Reply-To: <953beacc0611211151t472c88aegcdef5e8781d905fb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound open issues from IETF 67 Thread-Index: AccNp+cZHTO1duafRoW5JDbs8zKfGQAYZgxA From: To: X-OriginalArrivalTime: 22 Nov 2006 07:44:44.0718 (UTC) FILETIME=[13C04CE0:01C70E0A] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Rohan, Just to verify that I understood your answer correctly: >If the first hop edge proxy (the P-CSCF) doesn't support outbound, it >will not add the 'ob' parameter to the Path header, so the registrar >will ignore the reg-id parameter in the request. ... and when the registrar ignores the reg-id within REGISTER it will not add the Supported: outbound header to the 200 OK response. And when the UA finds that the 200 OK does not contain Supported: outbound it finds out that it will not be able to try multiple registrations. Please tell if you meant this or something different. Thanks, Erkki >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 >Sent: 21.November.2006 21:52 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: rohan@ekabal.com; sip@ietf.org >Subject: Re: [Sip] outbound open issues from IETF 67 > >Hi Erkki, > >If the first hop edge proxy (the P-CSCF) doesn't support outbound, it >will not add the 'ob' parameter to the Path header, so the registrar >will ignore the reg-id parameter in the request. > >hope this helps. >thanks, >-rohan > >On 11/21/06, Erkki.Koivusalo@nokia.com=20 > wrote: >> >> Hi Rohan, >> >> I do not have any objections to any of the proposals you made >> for Outbound. However I have a question related to the Issue 3G >> you had on your slideset. The slideset outlined the 3GPP requirement >> as follows: >> >> - 3GPP and others want to store multiple path vectors back to an >> instance, each associated with a reg-id. >> - New registrations with the same reg-id would replace the=20 >old binding. >> * BUT 3GPP wants to do this unrelated to outbound flow-token >> processing >> * 3GPP wants separation of binding behavior and flow-token >> behavior >> * Why? Their IPsec UDP uses several pairs of actual flows, >> instead of just one. >> >> In 3GPP there is also a backwards compatibility issue related >> to the IPSec SA management in the edge proxy (P-CSCF). Old >> implementations not supporting Outbound would drop the old >> logical flow (IPSec SA) if the UA registers with a new reg-id >> and IP address. Thus the UA should be able to make sure that >> the edge proxy supports the new behaviour, before trying to >> establish multiple flows over different access networks >> towards the single edge proxy. >> >> They have been proposing a new option tag for this purpose, >> something like this: >> >> Name: mreg >> Description: This option-tag is used to identify SIP servers which >> are able to maintain multiple logical flows per UA instance. >> >> What do you think about this proposal ? >> >> Regards, >> >> Erkki >> >> >-----Original Message----- >> >From: ext Rohan Mahy [mailto:rohan@ekabal.com] >> >Sent: 20.November.2006 21:21 >> >To: sip@ietf.org >> >Cc: Rohan Mahy >> >Subject: [Sip] outbound open issues from IETF 67 >> > >> >Hi Folks, >> > >> >I've incorporated all the changes we agreed to at IETF67. For >> >those who >> >have not seen them yet, please consult the slides available here: >> >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf >> > >> >In addition, I have proposed text for Issues D&E (see below). >> > >> >In summary, we agreed from the meeting: >> >- Consensus to use 430 response >> >- Consensus to keep the "stable flow timer" >> >Bug A: No objection to fixing this bug >> >Issue B: consensus to only require 1st hop and registrar to=20 >participate >> >Issue C: consensus for No Action >> >Issue D: did not discuss, proposal mentioned below >> >Issue E: did not discuss, proposal mentioned below >> >Issue F: consensus for No Action >> >Issue 3G: rough consensus to Accept action 2 >> > >> >(Bug A): Provided mention of the 'rport' parameter. >> > >> >(Issue 3G): Relaxed flow-token language slightly. Instead=20 >of flow-token >> >saving specific UDP address/port tuples over which the=20 >request arrived, >> >make language fuzzy to save token which points to a 'logical >> >flow' that is >> >known to deliver data to that specific UA instance. >> > >> >(Issue B): Changed registrar verification so that only >> >first-hop proxy and >> >the registrar need to support outbound. Other intermediaries >> >in between >> >do not any more. >> > >> >(Issues D&E): Proposal text: >> >The UAC can situationally decide whether to request outbound >> >behavior by >> >including or omitting the 'reg-id' parameter. For example,=20 >imagine the >> >outbound-proxy-set contains two proxies in different domains, >> >EP1 and EP2. >> > If an outbound-style registration succeeded for a flow >> >through EP1, the >> >UA might decide to include 'outbound' in its option-tag when >> >registering >> >with EP2, in order to insure consistency. Similarly, if the >> >registration >> >through EP1 did not support outbound, the UA might decide=20 >to omit the >> >'reg-id' parameter when registering with EP2. >> > >> >I believe the proposed text for D&E is sufficient and=20 >should be fairly >> >non-controversial. If anyone has any objections, please=20 >speak up ASAP >> >(and *send text* ;-). >> > >> >thanks, >> >-rohan >> > >> > >> >_______________________________________________ >> >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >This list is for NEW development of the core SIP Protocol >> >Use sip-implementors@cs.columbia.edu for questions on current sip >> >Use sipping@ietf.org for new developments on the application of sip >> > >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From cecilialisabeth@surikoff.ru Wed Nov 22 07:01:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmqmz-0001LF-Q5 for sip-archive@lists.ietf.org; Wed, 22 Nov 2006 07:01:17 -0500 Received: from [221.219.226.86] (helo=gdhopepin) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gmqmx-0008TB-Pk for sip-archive@lists.ietf.org; Wed, 22 Nov 2006 07:01:17 -0500 Message-ID: <001401c70e27.1c9e5380.632dc0a8@gherardo> Date: Wed, 22 Nov 2006 11:12:35 +0000 From: sydelle alanah User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: sheeree nate Subject: Jus look at this! Content-Type: multipart/alternative; boundary="---------000000C9.01C70E27" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. -----------000000C9.01C70E27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pleasure shouldnt end fast! Proove her that you love her forever! http://biggh.com/et/ Alexander's doctors experimented with ointments of types and knowing them because the Moon -----------000000C9.01C70E27 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Pleasure shouldnt end fast!
Proove her that you love her forever!
http://biggh.com/et/
Alexander's doctors experimented with ointments of
types and knowing them
because the Moon
-----------000000C9.01C70E27-- From sip-bounces@ietf.org Wed Nov 22 08:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmrfw-00083x-7V; Wed, 22 Nov 2006 07:58:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmrfu-00083j-8H for sip@ietf.org; Wed, 22 Nov 2006 07:58:02 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmrfs-0006CG-RK for sip@ietf.org; Wed, 22 Nov 2006 07:58:02 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAMCuT7j014725; Wed, 22 Nov 2006 14:57:45 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:57:41 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:57:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Wed, 22 Nov 2006 14:57:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccN3SAfS3WFQhIqSWChufD81vt8MwAV+RMA From: To: , X-OriginalArrivalTime: 22 Nov 2006 12:57:41.0158 (UTC) FILETIME=[CB61AC60:01C70E35] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Dean Willis wrote: > >3) TCP is less desirable for mobile use because each proxy=20 >attachment requires three more packets (the TCP handshake),=20 >and the extra two seconds this might require at startup on a=20 >slow GPRS link is a show stopper. > >Response: Big fat hairy deal. > Clearly this does not apply to Outbound at all, since there the TCP connection is anyway maintained persistently in order to be reachable behind a NAT. So, at least from a mobile client point of view, this is not an issue.=20 Markus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 09:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsuC-0007SW-0m; Wed, 22 Nov 2006 09:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsuB-0007SR-83 for sip@ietf.org; Wed, 22 Nov 2006 09:16:51 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmsuA-0006T4-1v for sip@ietf.org; Wed, 22 Nov 2006 09:16:51 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (sccrmhc14) with SMTP id <2006112214164901400me83je>; Wed, 22 Nov 2006 14:16:49 +0000 Message-ID: <0a0f01c70e40$6f486620$6a01a8c0@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" , "Aki Niemi" References: <7374777208BDC7449D5620EF942325676E7C67@esealmw113.eemea.ericsson.se><1164029015.7482.23.camel@macbuster.research.nokia.com> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Wed, 22 Nov 2006 08:13:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" , "ext Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I happen to agree with Dean's suggested responses, I'm just offering more detail on this one. > 2) TCP may cause the consumption of more resources in the mobile radio > networks (specifically the battery) because of all those retransmissions > and keepalives. > > Response: Of course, outbound with UDP doesn't fare much better in this > case, as we're still doing keepalives, and TCP's keepalives can be turned > down or off anyhow. The default in the TCP specifications is a two-hour keepalive, turned off. If your TCP stack does something else, one might wonder "why?" When we are not retransmitting UDP packets, concern about TCP retransmissions makes sense, but we are talking about SIP signaling, so needed retransmissions need to happen in either UDP or TCP. Assuming that there's not a double-secret UDP retransmission mechanism that doesn't use battery power... :-) Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 11:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv43-0005Ks-3K; Wed, 22 Nov 2006 11:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv41-0005KS-3x for sip@ietf.org; Wed, 22 Nov 2006 11:35:09 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmv3l-0008B9-Vo for sip@ietf.org; Wed, 22 Nov 2006 11:35:09 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id kAMGYhGP016496; Wed, 22 Nov 2006 09:34:43 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Wed, 22 Nov 2006 09:34:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Date: Wed, 22 Nov 2006 09:34:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] strawman text for FASTEST proposal in outbound Thread-Index: AccN0/DhaVfBQAGgTxakDnaeYahaJgAer/Ug From: "Kevin Johns" To: "Rohan Mahy" , "Francois Audet" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I am in favor of FASTEST, however I am not sure the text being proposed is necessary. How does outbound prohibit the change to TCP? This seems to be an issue of how the algorithm for generating the flow token is implemented and those in outbound are informational from my reading. Thus, as long as the edge proxy utilizes an algorithm which generates a flow token which resolves to a source IP and Port and Destination IP and Port the edge proxy would be free to determine which transport protocol to use. If a NAT is present, the UA will need to establish both a UDP and TCP flow to the edge proxy to allow inbound requests on either. If a NAT is not present, then the UA need only establish one flow as the edge proxy can initial the other flow if needed. Kevin =20 -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Tuesday, November 21, 2006 6:15 PM To: Francois Audet Cc: SIP WG; Cullen Jennings; Rohan Mahy Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Hi Francois, On 11/21/06, Francois Audet wrote: > > > To make the discussion about the outbound transport issues more=20 > > concrete, here is some strawman text for the "FASTEST" direction. > > > > thanks, > > -rohan > > > > PROPOSED TEXT: > > Use of outbound with UDP flows prevents messages larger than 1300=20 > > bytes from being delivered using TCP as described in > ^^^ > Shouldn't this say "UDP"? No. Outbound using UDP flows prevents the switchover to a congestion-controlled transport, such as TCP as described in this quote from RFC 3261: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [36] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 11:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvBo-0008FB-IO; Wed, 22 Nov 2006 11:43:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvBm-0008F2-UR for sip@ietf.org; Wed, 22 Nov 2006 11:43:10 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmvBk-0000uA-JD for sip@ietf.org; Wed, 22 Nov 2006 11:43:10 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kAMGh1227956; Wed, 22 Nov 2006 08:43:01 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05a1bfb70d58cefa8a9024c6ac49a46a@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Date: Wed, 22 Nov 2006 08:39:50 -0800 To: X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, fluffy@cisco.com, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 22, 2006, at 6:11, wrote: > Hi, > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com] >> >> Hi, >> >> To make the discussion about the outbound transport issues >> more concrete, here is some strawman text for the "FASTEST" direction. >> >> thanks, >> -rohan >> >> PROPOSED TEXT: >> Use of outbound with UDP flows prevents messages larger than >> 1300 bytes from being delivered using TCP as described in >> Section 18.1.1 RFC 3261. Use of outbound in conjunction with >> UDP flows in environments where requests are expected to be >> larger than this size is therefore NOT RECOMMENDED. >> > > Practical question: In which kind of environment the messages could be > expected to always be below 1300 bytes? Folks using Sigcomp between the edge proxy and the UA. > Some kind of isolated island of > SIP where all endpoints and their features are under control? Possibly. thanks, -rohan > Clearly, > this won't work in any real inter-domain Internet deployment, and might > actually make such a thing even harder to achieve. Isn't this just evil > from the perspective of long-term well-being and deployment of SIP? :O > > Markus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 11:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvNM-0002H0-Ue; Wed, 22 Nov 2006 11:55:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmvNL-0002Gg-98 for sip@ietf.org; Wed, 22 Nov 2006 11:55:07 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmvNI-0002Uw-Ki for sip@ietf.org; Wed, 22 Nov 2006 11:55:07 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAMEBjL7011557; Wed, 22 Nov 2006 16:14:03 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 16:11:12 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 16:11:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Date: Wed, 22 Nov 2006 16:11:12 +0200 Message-ID: In-Reply-To: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] strawman text for FASTEST proposal in outbound Thread-Index: AccNrwpvQGXvAnATQaWQauKIZ/rK0AAhugwQ From: To: , X-OriginalArrivalTime: 22 Nov 2006 14:11:11.0985 (UTC) FILETIME=[10707610:01C70E40] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: fluffy@cisco.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > >Hi, > >To make the discussion about the outbound transport issues=20 >more concrete, here is some strawman text for the "FASTEST" direction. > >thanks, >-rohan > >PROPOSED TEXT: >Use of outbound with UDP flows prevents messages larger than=20 >1300 bytes from being delivered using TCP as described in=20 >Section 18.1.1 RFC 3261. Use of outbound in conjunction with=20 >UDP flows in environments where requests are expected to be=20 >larger than this size is therefore NOT RECOMMENDED. > Practical question: In which kind of environment the messages could be expected to always be below 1300 bytes? Some kind of isolated island of SIP where all endpoints and their features are under control? Clearly, this won't work in any real inter-domain Internet deployment, and might actually make such a thing even harder to achieve. Isn't this just evil from the perspective of long-term well-being and deployment of SIP? :O=20 Markus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 13:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwzU-0004yb-4r; Wed, 22 Nov 2006 13:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwzS-0004yV-FD for sip@ietf.org; Wed, 22 Nov 2006 13:38:34 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmwzO-0001zq-Ok for sip@ietf.org; Wed, 22 Nov 2006 13:38:34 -0500 Received: by ug-out-1314.google.com with SMTP id 72so221227ugd for ; Wed, 22 Nov 2006 10:38:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=db3/aiGpBOcfNzMNsaJ47ORAAXVYhMsNHXdXYGHO0OT7J/wHWr86zxYKuTpVH2YWVAonecR9FBSnI0Vw9LwhkCcj1s5oKtotqCczCgoMRVBdGaFqr6R+TQbED5fJ+0RHZL4hCzCR3fC+50yJjqkuO0gmCy+oKQUnKyFjUHHN8No= Received: by 10.78.157.8 with SMTP id f8mr8129495hue.1164220706353; Wed, 22 Nov 2006 10:38:26 -0800 (PST) Received: by 10.78.200.9 with HTTP; Wed, 22 Nov 2006 10:38:26 -0800 (PST) Message-ID: <953beacc0611221038o49bf598ci8d3f2995d3b643ae@mail.gmail.com> Date: Wed, 22 Nov 2006 10:38:26 -0800 From: "Rohan Mahy" To: "Erkki.Koivusalo@nokia.com" Subject: Re: [Sip] outbound open issues from IETF 67 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03060ECE@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0611211151t472c88aegcdef5e8781d905fb@mail.gmail.com> <8B1D53AEF7B03449A6D3771B3B7F850F03060ECE@esebe103.NOE.Nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 11/21/06, Erkki.Koivusalo@nokia.com wrote: > > Hi Rohan, > > Just to verify that I understood your answer correctly: > > >If the first hop edge proxy (the P-CSCF) doesn't support outbound, it > >will not add the 'ob' parameter to the Path header, so the registrar > >will ignore the reg-id parameter in the request. > > ... and when the registrar ignores the reg-id within REGISTER it will > not add the Supported: outbound header to the 200 OK response. > And when the UA finds that the 200 OK does not contain Supported: > outbound it finds out that it will not be able to try multiple registrations. Correct. thanks, -rohan > Please tell if you meant this or something different. > > Thanks, > > Erkki > > >-----Original Message----- > >From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com] > >Sent: 21.November.2006 21:52 > >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > >Cc: rohan@ekabal.com; sip@ietf.org > >Subject: Re: [Sip] outbound open issues from IETF 67 > > > >Hi Erkki, > > > >If the first hop edge proxy (the P-CSCF) doesn't support outbound, it > >will not add the 'ob' parameter to the Path header, so the registrar > >will ignore the reg-id parameter in the request. > > > >hope this helps. > >thanks, > >-rohan > > > >On 11/21/06, Erkki.Koivusalo@nokia.com > > wrote: > >> > >> Hi Rohan, > >> > >> I do not have any objections to any of the proposals you made > >> for Outbound. However I have a question related to the Issue 3G > >> you had on your slideset. The slideset outlined the 3GPP requirement > >> as follows: > >> > >> - 3GPP and others want to store multiple path vectors back to an > >> instance, each associated with a reg-id. > >> - New registrations with the same reg-id would replace the > >old binding. > >> * BUT 3GPP wants to do this unrelated to outbound flow-token > >> processing > >> * 3GPP wants separation of binding behavior and flow-token > >> behavior > >> * Why? Their IPsec UDP uses several pairs of actual flows, > >> instead of just one. > >> > >> In 3GPP there is also a backwards compatibility issue related > >> to the IPSec SA management in the edge proxy (P-CSCF). Old > >> implementations not supporting Outbound would drop the old > >> logical flow (IPSec SA) if the UA registers with a new reg-id > >> and IP address. Thus the UA should be able to make sure that > >> the edge proxy supports the new behaviour, before trying to > >> establish multiple flows over different access networks > >> towards the single edge proxy. > >> > >> They have been proposing a new option tag for this purpose, > >> something like this: > >> > >> Name: mreg > >> Description: This option-tag is used to identify SIP servers which > >> are able to maintain multiple logical flows per UA instance. > >> > >> What do you think about this proposal ? > >> > >> Regards, > >> > >> Erkki > >> > >> >-----Original Message----- > >> >From: ext Rohan Mahy [mailto:rohan@ekabal.com] > >> >Sent: 20.November.2006 21:21 > >> >To: sip@ietf.org > >> >Cc: Rohan Mahy > >> >Subject: [Sip] outbound open issues from IETF 67 > >> > > >> >Hi Folks, > >> > > >> >I've incorporated all the changes we agreed to at IETF67. For > >> >those who > >> >have not seen them yet, please consult the slides available here: > >> >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf > >> > > >> >In addition, I have proposed text for Issues D&E (see below). > >> > > >> >In summary, we agreed from the meeting: > >> >- Consensus to use 430 response > >> >- Consensus to keep the "stable flow timer" > >> >Bug A: No objection to fixing this bug > >> >Issue B: consensus to only require 1st hop and registrar to > >participate > >> >Issue C: consensus for No Action > >> >Issue D: did not discuss, proposal mentioned below > >> >Issue E: did not discuss, proposal mentioned below > >> >Issue F: consensus for No Action > >> >Issue 3G: rough consensus to Accept action 2 > >> > > >> >(Bug A): Provided mention of the 'rport' parameter. > >> > > >> >(Issue 3G): Relaxed flow-token language slightly. Instead > >of flow-token > >> >saving specific UDP address/port tuples over which the > >request arrived, > >> >make language fuzzy to save token which points to a 'logical > >> >flow' that is > >> >known to deliver data to that specific UA instance. > >> > > >> >(Issue B): Changed registrar verification so that only > >> >first-hop proxy and > >> >the registrar need to support outbound. Other intermediaries > >> >in between > >> >do not any more. > >> > > >> >(Issues D&E): Proposal text: > >> >The UAC can situationally decide whether to request outbound > >> >behavior by > >> >including or omitting the 'reg-id' parameter. For example, > >imagine the > >> >outbound-proxy-set contains two proxies in different domains, > >> >EP1 and EP2. > >> > If an outbound-style registration succeeded for a flow > >> >through EP1, the > >> >UA might decide to include 'outbound' in its option-tag when > >> >registering > >> >with EP2, in order to insure consistency. Similarly, if the > >> >registration > >> >through EP1 did not support outbound, the UA might decide > >to omit the > >> >'reg-id' parameter when registering with EP2. > >> > > >> >I believe the proposed text for D&E is sufficient and > >should be fairly > >> >non-controversial. If anyone has any objections, please > >speak up ASAP > >> >(and *send text* ;-). > >> > > >> >thanks, > >> >-rohan > >> > > >> > > >> >_______________________________________________ > >> >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> >This list is for NEW development of the core SIP Protocol > >> >Use sip-implementors@cs.columbia.edu for questions on current sip > >> >Use sipping@ietf.org for new developments on the application of sip > >> > > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 16:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmzbl-0006rC-6u; Wed, 22 Nov 2006 16:26:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmzbj-0006q7-9M for sip@ietf.org; Wed, 22 Nov 2006 16:26:15 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmzbe-0006Pr-Vu for sip@ietf.org; Wed, 22 Nov 2006 16:26:15 -0500 Received: by ug-out-1314.google.com with SMTP id 72so261989ugd for ; Wed, 22 Nov 2006 13:26:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=tf9g5bFSwuxCVma/Gz37f15goFOypMyrc6PH7uj6NEycautudU261yeELSg4+V1gSjGF/QyhMDnbS10C8egmcsKqk7v9QPdcC4U4D4IJrs1JbkJSV7kmBTwHl9f0bT/qD8bW0IXfiuADUCJcTovEOobRGX4syXr9MHll4REovoA= Received: by 10.78.127.2 with SMTP id z2mr8319225huc.1164230769448; Wed, 22 Nov 2006 13:26:09 -0800 (PST) Received: by 10.78.200.9 with HTTP; Wed, 22 Nov 2006 13:26:09 -0800 (PST) Message-ID: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> Date: Wed, 22 Nov 2006 13:26:09 -0800 From: "Rohan Mahy" To: "SIP WG" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] outbound-06 submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I submitted -06 of outbound so folks can at least take a look to see that the many small changes we have agreed to have been incorporated. I also included the proposed text for FASTEST, since the draft would need significant surgery anyway if we go with CLEANEST. Until it appears in the archive you can find it here: http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-06.html http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-06.txt thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 16:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn01V-0001aw-Ee; Wed, 22 Nov 2006 16:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn01U-0001ao-JU for sip@ietf.org; Wed, 22 Nov 2006 16:52:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn01Q-0002dA-7n for sip@ietf.org; Wed, 22 Nov 2006 16:52:52 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 13:52:47 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kAMLqk8b031588; Wed, 22 Nov 2006 13:52:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAMLqPOf019682; Wed, 22 Nov 2006 13:52:38 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 13:52:30 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 13:52:29 -0800 Message-ID: <4564C69C.40402@cisco.com> Date: Wed, 22 Nov 2006 16:52:28 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Re: New work: Option-tag for ICE References: <50B1CBA96870A34799A506B2313F26670A6112E8@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A6112E8@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2006 21:52:29.0693 (UTC) FILETIME=[81A38AD0:01C70E80] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1709; t=1164232366; x=1165096366; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20New=20work=3A=20Option-tag=20for=20IC E |Sender:=20; bh=2SGDLwtbh1ARub/kgCu4U0phYW6p4ajBjwO2HunPVVY=; b=tVBJQaZX6kAsQoG/dRgLOuK5PMulBeCi0nTCkLn4uVdYCUYE0WPfz62l7tFoxpelBv86XVHq oigQhvv1QfczADNgTmJlP84CJLmN8ArTgWiXIwq1yUxY3b9/gYsHgzcq; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Elwell, John wrote: >>If there's a tag in the registered contact for the UA that >>the offerless >>INVITE is for though, then the INVITE going out could have the option >>tag in it (as the B2BUA would know something about the UA it's >>initiating 3PCC for). > > [JRE] I don't think this is a reasonable assumption. The B2BUA is initiating > a call from A to B, where A is in its domain, say, but B could be anywhere. > It sends an offerless INVITE to A. It is unlikely to know the capabilities > of B. > Yes, I appreciate that it can also happen the opposite way round, in which > case the option tag could work. The point is, there are so many > circumstances in which an offerless INVITE can be used that I don't think it > is reasonable to assume that the absence of Supported: ice means that ICE is > definitely not supported. This is an excellent point. I think you are correct; since a UA cannot differentiate between a first and third party offerless invite, it would need to always construct its offer with ICE attributes, regardless of the presence of the option tag. In this case, the option tag is pointless since its presence has no bearing on the processing the UA will execute. It would be nice to be able to differentiate the third vs. first party case, but there is nothing for that right now. The REGISTER case is definitely useful, and there is a not-so-useful but possible application with Require in an INVITE. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 22 17:07:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0FI-0001wd-TA; Wed, 22 Nov 2006 17:07:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0FH-0001wV-5T for sip@ietf.org; Wed, 22 Nov 2006 17:07:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn0FE-0005cM-F7 for sip@ietf.org; Wed, 22 Nov 2006 17:07:07 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 14:07:04 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAMM73F2027911; Wed, 22 Nov 2006 14:07:03 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAMM73in026233; Wed, 22 Nov 2006 14:07:03 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:07:03 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:07:02 -0800 Message-ID: <4564CA05.4010505@cisco.com> Date: Wed, 22 Nov 2006 17:07:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Re: New work: Option-tag for ICE References: <6FC4416DDE56C44DA0AEE67BC7CA437111820DA8@zrc2hxm2.corp.nortel.com> <001801c70a6c$06873b20$0601a8c0@BEMBUSTER> In-Reply-To: <001801c70a6c$06873b20$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2006 22:07:02.0974 (UTC) FILETIME=[8A27A5E0:01C70E82] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5084; t=1164233223; x=1165097223; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20New=20work=3A=20Option-tag=20for=20IC E |Sender:=20; bh=yv+u0Jg1CWNVP5XGfrdbGhh8iNMk+RdiY4MibF/nHFs=; b=tQhH/ou1X3oCY0LewRMjtHAggv01zYMYTKgrUWpUksEarymYj6QMbZ8PNLUCe2eD4EtnjojW iGaPjLdWgD9dI+LFrG4nZDNcok6tyuaWIJSYWEJQ8ebBHwRw2PKexpCR; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In the REGISTER case, I think its probably *slightly* more correct to use a capability and not an option tag. This is because you could have a third party registration, with different ICE support for different contacts in the registration. FWIW I am very sour these days on third party registrations; indeed, I've gone as far as to propose deprecating them as part of UA's compliant to route-construct: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-02.txt That said, we do need an option tag in the case of a Require header in an INVITE. Per the other thread I think I've concluded its not useful in an offerless INVITE. For presence documents, either would work (though an option tag is simpler since it doesn't require a prescaps extension). So, my proposal would be to define both, and use the callee cap in registrations. Option tag would just be for Require. -Jonathan R. Jeroen van Bemmel wrote: > In that case, how about a callee capability instead / in addition > (RFC3840)? > i.e. a UA would form its Contact as: > > Contact: ;+sip.ice > > Regards, > Jeroen > > > Brian Stucker wrote: > >> I think the idea of having an option tag in the REGISTER is a good >> idea. It may be helpful when the network is trying to initiate a call >> to the client. >> >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>> Sent: Monday, November 13, 2006 10:48 AM >>> To: Drage, Keith (Keith) >>> Cc: IETF SIP List >>> Subject: [Sip] Re: New work: Option-tag for ICE >>> >>> The semantics for the option tag are the same as for any >>> other option tag - it means that ICE is supported. >>> >>> ICE is normally signaled through SDP attributes, and there is >>> no need for an option tag for the "normal" call flows. >>> However, we ran into some issues with offerless INVITEs. In >>> particular, it would be really, really helpful for a UA to >>> construct an offer in a 18x or 2xx based on knowledge of >>> whether the UA that sent the INVITE supports ICE. If they >>> don't, there is no need to gather candidates in constructing >>> an offer in the response. >>> >>> Another use case that was suggested was to place the option >>> tag in a REGISTER. This would inform the "network" about >>> whether the UA supports ICE, and can be helpful in some of >>> the backwards-compatibility techniques that people are looking at. >>> >>> Thanks, >>> Jonathan R. >>> >>> Drage, Keith (Keith) wrote: >>> >>>> (As SIP WG chair) >>>> >>>> As part of the ICE discussion in MMUSIC, it has been >>> >>> identified that >>> >>>> there is a need for an option tag. RFC 3427 says that documents >>>> specifying these need to be presented to IESG by SIP. Rather than >>>> transfer the entirety of ICE back to SIP, the proposal is >>> >>> to create a >>> >>>> separate draft that specifies this option tag and pursue >>> >>> this in SIP. >>> >>>> >>>> I would appreciate if Jonathan would post to this list a >>> >>> some idea of >>> >>>> the semantics of the new option tag. >>>> >>>> The intention of the SIP WG chairs is therefore to request >>> >>> the ADs to >>> >>>> approve a new milestone in this area. >>>> >>>> Therefore does anyone in the SIP WG have an issue with the >>> >>> creation of >>> >>>> a new WG item that specifies such a new option-tag. This is intended >>>> to be a fairly short term activity (as ICE is regarded as >>> >>> pretty much >>> >>>> finished) so please respond quickly. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> Keith Drage >>>> drage@lucent.com >>>> tel: +44 1793 776249 >>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Cisco Fellow Parsippany, NJ >>> 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From jacquiangelina@janetbainco.com Wed Nov 22 22:51:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn5cl-0003Cs-AO for sip-archive@lists.ietf.org; Wed, 22 Nov 2006 22:51:43 -0500 Received: from ip216-239-68-92.vif.net ([216.239.68.92] helo=lhomp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gn5cf-000439-Sz for sip-archive@lists.ietf.org; Wed, 22 Nov 2006 22:51:43 -0500 Message-ID: <00b001c70eab.ec4cc880.3283c0a8@ephrayim> Date: Thu, 23 Nov 2006 03:03:17 +0000 From: darby oralla User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: caldwell ezequiel Subject: My dear Content-Type: multipart/alternative; boundary="---------0000003F.01C70EAB" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. -----------0000003F.01C70EAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pleasure shouldnt end fast! Proove her that you love her forever! http://easyri.com/et/ unease grew steadily. Still, makes things real. The collapse have lost. These Macedonians -----------0000003F.01C70EAB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Pleasure shouldnt end fast!
Proove her that you love her forever!
http://easyri.com/et/
unease grew steadily. Still,
makes things real. The collapse
have lost. These Macedonians
-----------0000003F.01C70EAB-- From sip-bounces@ietf.org Thu Nov 23 04:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAon-00072k-54; Thu, 23 Nov 2006 04:24:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAom-000729-6I for sip@ietf.org; Thu, 23 Nov 2006 04:24:28 -0500 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnAoh-00034E-5J for sip@ietf.org; Thu, 23 Nov 2006 04:24:28 -0500 Received: from Inbox ([89.205.141.237]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9600GTYFG5NU00@jes-fe1.zx.nl> for sip@ietf.org; Thu, 23 Nov 2006 10:24:22 +0100 (CET) Date: Thu, 23 Nov 2006 10:24:16 +0100 From: Jeroen Van Bemmel Subject: RE: [Sip] Re: New work: Option-tag for ICE To: Jonathan Rosenberg Message-id: <0J9600GU0FGFNU00@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > In the REGISTER case, I think its probably *slightly* more correct to=20 use a capability and not an option tag. This is because you could have a=20 third party registration, with different ICE support for different=20 contacts in the registration. (JvB) That, plus the discussion we had on the scope of require/supported be= ing limited to the transaction. Regards, Jeroen = _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 23 04:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAob-0006zH-Cd; Thu, 23 Nov 2006 04:24:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAoa-0006yl-1P for sip@ietf.org; Thu, 23 Nov 2006 04:24:16 -0500 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnAoY-00030y-Mk for sip@ietf.org; Thu, 23 Nov 2006 04:24:16 -0500 Received: from Inbox ([89.205.141.237]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9600GTYFG5NU00@jes-fe1.zx.nl> for sip@ietf.org; Thu, 23 Nov 2006 10:24:13 +0100 (CET) Date: Thu, 23 Nov 2006 10:24:06 +0100 From: Jeroen Van Bemmel Subject: RE: [Sip] outbound-06 submitted To: Rohan Mahy , SIP WG Message-id: <0J9600GTZFG6NU00@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-SubscribeFrom sip-bounces@ietf.org Thu Nov 23 04:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAon-00072k-54; Thu, 23 Nov 2006 04:24:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAom-000729-6I for sip@ietf.org; Thu, 23 Nov 2006 04:24:28 -0500 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnAoh-00034E-5J for sip@ietf.org; Thu, 23 Nov 2006 04:24:28 -0500 Received: from Inbox ([89.205.141.237]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9600GTYFG5NU00@jes-fe1.zx.nl> for sip@ietf.org; Thu, 23 Nov 2006 10:24:22 +0100 (CET) Date: Thu, 23 Nov 2006 10:24:16 +0100 From: Jeroen Van Bemmel Subject: RE: [Sip] Re: New work: Option-tag for ICE To: Jonathan Rosenberg Message-id: <0J9600GU0FGFNU00@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > In the REGISTER case, I think its probably *slightly* more correct to=20 use a capability and not an option tag. This is because you could have a=20 third party registration, with different ICE support for different=20 contacts in the registration. (JvB) That, plus the discussion we had on the scope of require/supported be= ing limited to the transaction. Regards, Jeroen = _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 23 04:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAob-0006zH-Cd; Thu, 23 Nov 2006 04:24:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnAoa-0006yl-1P for sip@ietf.org; Thu, 23 Nov 2006 04:24:16 -0500 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnAoY-00030y-Mk for sip@ietf.org; Thu, 23 Nov 2006 04:24:16 -0500 Received: from Inbox ([89.205.141.237]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9600GTYFG5NU00@jes-fe1.zx.nl> for sip@ietf.org; Thu, 23 Nov 2006 10:24:13 +0100 (CET) Date: Thu, 23 Nov 2006 10:24:06 +0100 From: Jeroen Van Bemmel Subject: RE: [Sip] outbound-06 submitted To: Rohan Mahy , SIP WG Message-id: <0J9600GTZFG6NU00@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, Why is 430 limited to connection-oriented transports? If the edge proxy cho= oses to maintain state also for UDP, it can detect failed flows for UDP too Regards, Jeroen PS STUN acronym still outdated in this version -----Oorspronkelijk bericht ----- Van: "Rohan Mahy" Aan: "SIP WG" CC: "Cullen Jennings" ; "Rohan Mahy" Verzonden: 22-11-06 22:26 Onderwerp: [Sip] outbound-06 submitted Hi, I submitted -06 of outbound so folks can at least take a look to see that the many small changes we have agreed to have been incorporated. I also included the proposed text for FASTEST, since the draft would need significant surgery anyway if we go with CLEANEST. Until it appears in the archive you can find it here: http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-0= 6.html http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-0= 6.txt thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip : , Errors-To: sip-bounces@ietf.org Rohan, Why is 430 limited to connection-oriented transports? If the edge proxy cho= oses to maintain state also for UDP, it can detect failed flows for UDP too Regards, Jeroen PS STUN acronym still outdated in this version -----Oorspronkelijk bericht ----- Van: "Rohan Mahy" Aan: "SIP WG" CC: "Cullen Jennings" ; "Rohan Mahy" Verzonden: 22-11-06 22:26 Onderwerp: [Sip] outbound-06 submitted Hi, I submitted -06 of outbound so folks can at least take a look to see that the many small changes we have agreed to have been incorporated. I also included the proposed text for FASTEST, since the draft would need significant surgery anyway if we go with CLEANEST. Until it appears in the archive you can find it here: http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-0= 6.html http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-0= 6.txt thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 23 06:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCV9-0007aJ-58; Thu, 23 Nov 2006 06:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnC11-00009I-V4 for sip@ietf.org; Thu, 23 Nov 2006 05:41:11 -0500 Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnC10-0006QY-GT for sip@ietf.org; Thu, 23 Nov 2006 05:41:11 -0500 Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com [130.144.57.167]) by gw-eur4.philips.com (Postfix) with ESMTP id 4EB154973B for ; Thu, 23 Nov 2006 10:40:59 +0000 (UTC) Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id D941494E4 for ; Thu, 23 Nov 2006 10:38:34 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur4.philips.com (Postfix) with ESMTP id 917EF8D88 for ; Thu, 23 Nov 2006 10:38:31 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id EF6145B for ; Thu, 23 Nov 2006 10:38:30 +0000 (GMT) Importance: High In-Reply-To: <5D1A7985295922448D5550C94DE29180775653@DEEXC1U01.de.lucent.com> To: "IETF SIP List" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Thu, 23 Nov 2006 11:38:17 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.5HF805 | August 26, 2006) at 23/11/2006 11:38:22, Serialize complete at 23/11/2006 11:38:22 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Thu, 23 Nov 2006 06:12:17 -0500 Subject: [Sip] Multiplicity of SIP headers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0167561729==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0167561729== Content-Type: multipart/alternative; boundary="=_alternative 003A730AC125722F_=" This is a multipart message in MIME format. --=_alternative 003A730AC125722F_= Content-Type: text/plain; charset="US-ASCII" All, It seems that RFC 3261 does not say anything about the number of times that a header is allowed to apear in a request or response. The ABNF states: Request = Request-Line *( message-header ) CRLF [ message-body ] message-header = (Accept / Accept-Encoding : : / Accept-Language / extension-header) CRLF Which means that any header can appear any number of times. The text of the RFC does not seem to modify this in any way. So what does this mean? Is it indeed the case that a header may appear any number of times? Cheers, Frank --=_alternative 003A730AC125722F_= Content-Type: text/html; charset="US-ASCII"
All,

It seems that RFC 3261 does not say anything about the number of times that a
header is allowed to apear in a request or response. The ABNF states:

Request        =  Request-Line
                  *( message-header )
                  CRLF
                  [ message-body ]

message-header  =  (Accept
                /  Accept-Encoding
                        :
                        :
                /  Accept-Language
                /  extension-header) CRLF

Which means that any header can appear any number of times. The text of the RFC
does not seem to modify this in any way. So what does this mean? Is it indeed
the case that a header may appear any number of times?

Cheers,

Frank
--=_alternative 003A730AC125722F_=-- --===============0167561729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0167561729==-- From sip-bounces@ietf.org Thu Nov 23 06:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCfD-00036m-3F; Thu, 23 Nov 2006 06:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCfB-00036g-OA for sip@ietf.org; Thu, 23 Nov 2006 06:22:41 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnCf9-0006ko-FZ for sip@ietf.org; Thu, 23 Nov 2006 06:22:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Multiplicity of SIP headers Date: Thu, 23 Nov 2006 11:22:35 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23FEF@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Multiplicity of SIP headers thread-index: AccO8ObnmqzOmzDDSVCa6RIWeTgn0AAAQjZw From: "Attila Sipos" To: "Frank Derks" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757121150==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0757121150== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70EF1.ACD3E0E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70EF1.ACD3E0E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 In terms of pure grammar, headers can appear any number of times. =20 In practice, it only makes sense for some headers to appear multiple times (e.g. Route, Record-Route, Contact). And for some headers, an appearance of more than once has no use (well, not at the moment) (e.g. To and From). =20 Regards, =20 Attila =20 =20 -----Original Message----- From: Frank Derks [mailto:frank.derks@nec-philips.com] Sent: 23 November 2006 10:38 To: IETF SIP List Subject: [Sip] Multiplicity of SIP headers Importance: High All,=20 It seems that RFC 3261 does not say anything about the number of times = that a=20 header is allowed to apear in a request or response. The ABNF states:=20 Request =3D Request-Line=20 *( message-header )=20 CRLF=20 [ message-body ]=20 message-header =3D (Accept=20 / Accept-Encoding=20 :=20 :=20 / Accept-Language=20 / extension-header) CRLF=20 Which means that any header can appear any number of times. The text of = the RFC=20 does not seem to modify this in any way. So what does this mean? Is it = indeed=20 the case that a header may appear any number of times?=20 Cheers,=20 Frank=20 ------_=_NextPart_001_01C70EF1.ACD3E0E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
In=20 terms of pure grammar, headers can appear any number of=20 times.
 
In=20 practice, it only makes sense for some headers to = appear
multiple times (e.g. Route, Record-Route, = Contact).
And=20 for some headers, an appearance of more than once
has no=20 use (well, not at the moment) (e.g. To and = From).
 
Regards,
 
Attila
 
 
-----Original Message-----
From: Frank Derks=20 [mailto:frank.derks@nec-philips.com]
Sent: 23 November 2006=20 10:38
To: IETF SIP List
Subject: [Sip] = Multiplicity of SIP=20 headers
Importance: High


All,

It seems = that RFC 3261=20 does not say anything about the number of times that a =
header is allowed to apear in a request or = response. The=20 ABNF states:

Request =    =20    =3D  Request-Line
 =20                 *( = message-header=20 )
        =  =20         CRLF
 =20                 [ message-body = ]

message-header =  =3D=20  (Accept
    =    =20         /  Accept-Encoding
            =    =20         :
 =20                     =  =20 :
        =  =20       /  Accept-Language
                /=20  extension-header) CRLF

Which=20 means that any header can appear any number of times. The text of the=20 RFC
does not seem to modify = this in any=20 way. So what does this mean? Is it indeed
the case that a header may appear any number of times? =

Cheers,

Frank
------_=_NextPart_001_01C70EF1.ACD3E0E4-- --===============0757121150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0757121150==-- From robstavros@panssarivau.nu Thu Nov 23 06:44:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnD0F-000587-Hf for sip-archive@lists.ietf.org; Thu, 23 Nov 2006 06:44:27 -0500 Received: from [89.108.50.219] (helo=hdkfkmgilf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnD09-0001mf-4q for sip-archive@lists.ietf.org; Thu, 23 Nov 2006 06:44:27 -0500 Message-ID: <001501c70eed.d8c25180.8856c0a8@modestine> Date: Thu, 23 Nov 2006 10:55:11 +0000 From: hanny sela User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: forrest pavia Subject: Jus look at this! Content-Type: multipart/alternative; boundary="---------00000074.01C70EED" X-Spam-Score: 4.1 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. -----------00000074.01C70EED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pleasure shouldnt end fast! Proove her that you love her forever! http://gerush.com/et/ because the Moon out. Let's add it to the itinerary'we department; you're sexual deviant. You can -----------00000074.01C70EED Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Pleasure shouldnt end fast!
Proove her that you love her forever!
http://gerush.com/et/
because the Moon
out. Let's add it to the itinerary'we
department; you're sexual deviant. You can
-----------00000074.01C70EED-- From sip-bounces@ietf.org Thu Nov 23 07:06:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDKb-0006tE-Tx; Thu, 23 Nov 2006 07:05:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDKa-0006sm-Ta for sip@ietf.org; Thu, 23 Nov 2006 07:05:28 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnDKZ-0004nj-Kk for sip@ietf.org; Thu, 23 Nov 2006 07:05:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Multiplicity of SIP headers Date: Thu, 23 Nov 2006 12:05:26 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3665@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Multiplicity of SIP headers thread-index: AccO8/K6tmCI6NY1QH61UsLroxuH0QAATt/w From: "Attila Sipos" To: "Frank Derks" X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1373953169==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1373953169== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70EF7.A91F951E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70EF7.A91F951E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Frank, =20 I feel section "7.3.1 Header Field Format" is quite clear (with the example of Route headers) about equivalence. =20 defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. =20 .... Implementations MUST be able to process multiple header field = rows .... with the same name in any combination of the = single-value-per-line or .... comma-separated value forms. So it has to handle all of the above.=20 And the dotted part (....) is the most important. =20 >>unspecified and therefore completely dependent on twoe implementations = >>that happen to have taken the same approach. Although there's nothing=20 I feel it only requires that two implementations comply with section = 7.3.1. =20 All implementations need the flexibility to be able to handle the multiple header-values in combination with multiple sip headers (of the same type). If they don't, they don't comply. =20 Regards, Attila =20 =20 -----Original Message----- From: Frank Derks [mailto:frank.derks@nec-philips.com] Sent: 23 November 2006 11:39 To: Attila Sipos Cc: IETF SIP List Subject: RE: [Sip] Multiplicity of SIP headers Hi Atilla.=20 I agree that common sense should prevail when implementing this sort of = thing,=20 but it would also be useful to specify things in an exact manner to = prevent=20 problems.=20 As an example, you mention the Contact header as being one of those = headers=20 that could be present more than once. The specified way provide multiple = Contact addresses is through a comma-separated list of addresses in one=20 Contact header. The theoretical alternative could indeed be to provide=20 multiple Contact headers, each with one Contact address, but this is=20 unspecified and therefore completely dependent on twoe implementations=20 that happen to have taken the same approach. Although there's nothing=20 fundamentally wrong with multiple ways in which the same can be = achieved,=20 this should be specified and if possible avoided.=20 Cheers,=20 Frank=20 "Attila Sipos" =20 2006-11-23 12:22 PM=20 To "Frank Derks" "IETF SIP List" =20 cc Subject RE: [Sip] Multiplicity of SIP headers=20 Classification =09 =20 In terms of pure grammar, headers can appear any number of times.=20 =20 In practice, it only makes sense for some headers to appear=20 multiple times (e.g. Route, Record-Route, Contact).=20 And for some headers, an appearance of more than once=20 has no use (well, not at the moment) (e.g. To and From).=20 =20 Regards,=20 =20 Attila=20 =20 =20 -----Original Message----- From: Frank Derks [mailto:frank.derks@nec-philips.com] Sent: 23 November 2006 10:38 To: IETF SIP List Subject: [Sip] Multiplicity of SIP headers Importance: High All,=20 It seems that RFC 3261 does not say anything about the number of times = that a=20 header is allowed to apear in a request or response. The ABNF states:=20 Request =3D Request-Line=20 *( message-header )=20 CRLF=20 [ message-body ]=20 message-header =3D (Accept=20 / Accept-Encoding=20 :=20 :=20 / Accept-Language=20 / extension-header) CRLF=20 Which means that any header can appear any number of times. The text of = the RFC=20 does not seem to modify this in any way. So what does this mean? Is it = indeed=20 the case that a header may appear any number of times?=20 Cheers,=20 Frank=20 ------_=_NextPart_001_01C70EF7.A91F951E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi=20 Frank,
 
I feel = section=20 "7.3.1 Header Field Format" is = quite=20 clear
(with the example of Route headers) about=20 equivalence.
 
   defined in Section 7.3).  = It MUST be=20 possible to combine the multiple
   header field rows into = one=20 "field-name: field-value" pair, without
   changing the = semantics=20 of the message, by appending each subsequent
   field-value = to the=20 first, each separated by a comma.  The exceptions
   = to this=20 rule are the WWW-Authenticate, Authorization, Proxy-
  =20 Authenticate, and Proxy-Authorization header fields.  Multiple=20 header
   field rows with these names MAY be present in a = message, but=20 since
   their grammar does not follow the general form = listed in=20 Section 7.3,
   they MUST NOT be combined into a single = header=20 field row.
 
....   Implementations MUST = be able to=20 process multiple header field rows
....   with the same name in = any=20 combination of the single-value-per-line or
....   comma-separated value = forms.
So it=20 has to handle all of the above. 
And=20 the dotted part (....)  is the most important.
 
>>unspecified and therefore completely dependent = on twoe=20 implementations
>>that happen to have taken the = same=20 approach. Although there's nothing=20
I feel=20 it only requires that two implementations comply with section=20 7.3.1.
 
All=20 implementations need the flexibility to be able to handle=20 the
multiple header-values in combination with = multiple sip=20 headers
(of=20 the same type).  If they don't, they don't=20 comply.
 
Regards,
Attila
 
 
-----Original Message-----
From: Frank Derks=20 [mailto:frank.derks@nec-philips.com]
Sent: 23 November 2006=20 11:39
To: Attila Sipos
Cc: IETF SIP=20 List
Subject: RE: [Sip] Multiplicity of SIP=20 headers


Hi = Atilla.=20

I agree that common sense should = prevail=20 when implementing this sort of thing,
but=20 it would also be useful to specify things in an exact manner to = prevent=20
problems.

As an example, you mention the Contact header as being one of = those=20 headers
that could be present = more than=20 once. The specified way provide multiple
Contact addresses is through a comma-separated list of = addresses in=20 one
Contact header. The = theoretical=20 alternative could indeed be to provide
multiple Contact headers, each with one Contact address, but = this is=20
unspecified and therefore = completely=20 dependent on twoe implementations
that=20 happen to have taken the same approach. Although there's nothing=20
fundamentally wrong with = multiple ways in=20 which the same can be achieved,
this=20 should be specified and if possible avoided.

Cheers,

Frank=20











"Attila Sipos" = <Attila.Sipos@vegastream.com>

2006-11-23 12:22 PM =

To
"Frank Derks"=20 <frank.derks@nec-philips.com>
"IETF SIP List"=20 <sip@ietf.org>=20
cc
Subject
RE: [Sip] Multiplicity = of SIP=20 headers=20
Classification





 
In = terms of pure=20 grammar, headers can appear any number of times.
 
In = practice, it=20 only makes sense for some headers to appear
multiple times (e.g. Route, Record-Route, = Contact).=20
And for some headers, an = appearance of=20 more than once
has = no use (well,=20 not at the moment) (e.g. To and From).
 =20
Regards,
 
Attila=20
 
  =
-----Original Message-----
From: = Frank Derks=20 [mailto:frank.derks@nec-philips.com]
Sent: 23 November 2006=20 10:38
To: IETF SIP List
Subject: [Sip] = Multiplicity of SIP=20 headers
Importance: High


All,

It seems that RFC 3261 does not say anything about the = number of=20 times that a
header is allowed to apear in a request or response. = The ABNF=20 states:

Request=20        =3D  Request-Line=20
        =    =20      *( message-header ) =
            =  =20    CRLF
                =  [=20 message-body ]

message-header  =3D  (Accept=20
        =    =20    /  Accept-Encoding =
            =  =20          :
            =  =20          :
            =  =20  /  Accept-Language
               /=20  extension-header) CRLF

Which means that any header can appear any number of = times. The=20 text of the RFC
does=20 not seem to modify this in any way. So what does this mean? Is it=20 indeed
the case that=20 a header may appear any number of times? =

Cheers, =

Frank=20
------_=_NextPart_001_01C70EF7.A91F951E-- --===============1373953169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1373953169==-- From sip-bounces@ietf.org Thu Nov 23 10:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnG5o-0006Up-FQ; Thu, 23 Nov 2006 10:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnG5n-0006Uj-1E for sip@ietf.org; Thu, 23 Nov 2006 10:02:23 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnG5l-00024b-KE for sip@ietf.org; Thu, 23 Nov 2006 10:02:23 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kANF22Zf016411; Thu, 23 Nov 2006 09:02:02 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 09:02:02 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 16:02:00 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] outbound open issues from IETF 67 Date: Thu, 23 Nov 2006 16:01:59 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180846E9F@DEEXC1U01.de.lucent.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03060C56@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound open issues from IETF 67 Thread-Index: AccM2vJiy3PjIkueQJ+nLnCBrLAx5wAobaYgAGTjQtA= From: "Drage, Keith \(Keith\)" To: , , X-OriginalArrivalTime: 23 Nov 2006 15:02:00.0463 (UTC) FILETIME=[53E309F0:01C70F10] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org They, in this case, is I believe one organisation. The proposal was referred back until the requirements are known - in any case 3GPP cannot define option-tags. Keith=20 > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: 21 November 2006 15:11 > To: rohan@ekabal.com; sip@ietf.org > Subject: RE: [Sip] outbound open issues from IETF 67 >=20 >=20 > Hi Rohan, >=20 > I do not have any objections to any of the proposals you made=20 > for Outbound. However I have a question related to the Issue=20 > 3G you had on your slideset. The slideset outlined the 3GPP=20 > requirement as follows: >=20 > - 3GPP and others want to store multiple path vectors back to=20 > an instance, each associated with a reg-id. > - New registrations with the same reg-id would replace the=20 > old binding. > * BUT 3GPP wants to do this unrelated to outbound flow-token=20 > processing > * 3GPP wants separation of binding behavior and flow-token behavior > * Why? Their IPsec UDP uses several pairs of actual flows,=20 > instead of just one. >=20 > In 3GPP there is also a backwards compatibility issue related=20 > to the IPSec SA management in the edge proxy (P-CSCF). Old=20 > implementations not supporting Outbound would drop the old=20 > logical flow (IPSec SA) if the UA registers with a new reg-id=20 > and IP address. Thus the UA should be able to make sure that=20 > the edge proxy supports the new behaviour, before trying to=20 > establish multiple flows over different access networks=20 > towards the single edge proxy. >=20 > They have been proposing a new option tag for this purpose,=20 > something like this: >=20 > Name: mreg > Description: This option-tag is used to identify SIP servers which > are able to maintain multiple logical flows per UA instance. >=20 > What do you think about this proposal ?=20 >=20 > Regards, >=20 > Erkki >=20 > >-----Original Message----- > >From: ext Rohan Mahy [mailto:rohan@ekabal.com] > >Sent: 20.November.2006 21:21 > >To: sip@ietf.org > >Cc: Rohan Mahy > >Subject: [Sip] outbound open issues from IETF 67 > > > >Hi Folks, > > > >I've incorporated all the changes we agreed to at IETF67. For those=20 > >who have not seen them yet, please consult the slides available here: > >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf > > > >In addition, I have proposed text for Issues D&E (see below). > > > >In summary, we agreed from the meeting: > >- Consensus to use 430 response > >- Consensus to keep the "stable flow timer" > >Bug A: No objection to fixing this bug > >Issue B: consensus to only require 1st hop and registrar to=20 > participate=20 > >Issue C: consensus for No Action Issue D: did not discuss, proposal=20 > >mentioned below Issue E: did not discuss, proposal mentioned below=20 > >Issue F: consensus for No Action Issue 3G: rough consensus to Accept=20 > >action 2 > > > >(Bug A): Provided mention of the 'rport' parameter. > > > >(Issue 3G): Relaxed flow-token language slightly. Instead of=20 > flow-token=20 > >saving specific UDP address/port tuples over which the=20 > request arrived,=20 > >make language fuzzy to save token which points to a 'logical=20 > flow' that=20 > >is known to deliver data to that specific UA instance. > > > >(Issue B): Changed registrar verification so that only=20 > first-hop proxy=20 > >and the registrar need to support outbound. Other intermediaries in=20 > >between do not any more. > > > >(Issues D&E): Proposal text: > >The UAC can situationally decide whether to request outbound=20 > behavior=20 > >by including or omitting the 'reg-id' parameter. For=20 > example, imagine=20 > >the outbound-proxy-set contains two proxies in different domains, > >EP1 and EP2. > > If an outbound-style registration succeeded for a flow through EP1,=20 > >the UA might decide to include 'outbound' in its option-tag when=20 > >registering with EP2, in order to insure consistency. Similarly, if=20 > >the registration through EP1 did not support outbound, the UA might=20 > >decide to omit the 'reg-id' parameter when registering with EP2. > > > >I believe the proposed text for D&E is sufficient and should=20 > be fairly=20 > >non-controversial. If anyone has any objections, please=20 > speak up ASAP=20 > >(and *send text* ;-). > > > >thanks, > >-rohan > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 23 10:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGu6-0007mw-Qz; Thu, 23 Nov 2006 10:54:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGu5-0007mr-Tw for sip@ietf.org; Thu, 23 Nov 2006 10:54:21 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGu2-0002iM-9S for sip@ietf.org; Thu, 23 Nov 2006 10:54:21 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id kANFsEHG023631; Thu, 23 Nov 2006 16:54:15 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kANFsESS010388; Thu, 23 Nov 2006 16:54:14 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 16:54:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Requesting feedback on draft-dotson-sip-certificate-auth-01 Date: Thu, 23 Nov 2006 16:52:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Requesting feedback on draft-dotson-sip-certificate-auth-01 Thread-Index: AccNk1aBHIBGrGjpQpuIDMODz77mnQBgvgwg From: "Fries, Steffen" To: "Steve Dotson" , "IETF SIP List" X-OriginalArrivalTime: 23 Nov 2006 15:54:14.0185 (UTC) FILETIME=[9FBB1190:01C70F17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1203462367==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1203462367== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70F17.9F7169D5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70F17.9F7169D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, =20 having certificates for user registration over multiple hops on a registrar seems an interesting approach. The possibility to have a local authentication service on the user agent would help here, but in most scenarios, the user agent itself will not possess the domain certificate according to RFC4474. =20 Two comments to the transport of credentials. You mentioned that SIP identity itself does not provide for certificate transport. We are currently working on an update of a draft targeting a BCP for credential transport in SIP using SIP identity (http://www.ietf.org/internet-drafts/draft-fries-sip-identity-usage-bcp- 00.txt). Our draft also mentions the usage of SIP SAML to transport an assertion or a reference to an assertion, which may be interesting in your scenario as well. A SAML assertion could be provided by a local server, which in turn may be used to register the UA.=20 =20 Ciao Steffen =20 ________________________________ From: Steve Dotson [mailto:S.Dotson@CableLabs.com]=20 Sent: Tuesday, November 21, 2006 6:35 PM To: IETF SIP List Subject: [Sip] Requesting feedback on draft-dotson-sip-certificate-auth-01 =09 =09 Some industries and organizations have invested in PKI, and thus have certificates available for authentication. We would like to leverage those credentials for SIP authentication. Using certificates instead of UICCs or other credentials is attractive for certain deployment models. http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-01 .txt describes some requirements related to this issue, as well as a review of previous and related work. We have received good feedback offline from authors of related work which were incorporated into the latest draft. =20 Thanks, =20 Steve. =20 ------_=_NextPart_001_01C70F17.9F7169D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Steve,
 
having certificates for user registration over = multiple=20 hops on a registrar seems an interesting approach. The possibility to = have a=20 local authentication service on the user agent would help here, but in = most=20 scenarios, the user agent itself will not possess the domain certificate = according to RFC4474.
 
Two comments to the transport of credentials. = You mentioned=20 that SIP identity itself does not provide for certificate transport. We = are=20 currently working on an update of a draft targeting a BCP for credential = transport in SIP using SIP identity (http://www.ietf.org/internet-drafts/draft-fries-sip-identit= y-usage-bcp-00.txt).=20 Our draft also mentions the usage of SIP SAML to transport an assertion = or a=20 reference to an assertion, which may be interesting in your scenario as = well. A=20 SAML assertion could be provided by a local server, which in turn may be = used to=20 register the UA.
 
Ciao
    Steffen
 

From: Steve Dotson=20 [mailto:S.Dotson@CableLabs.com]
Sent: Tuesday, November 21, = 2006=20 6:35 PM
To: IETF SIP List
Subject: [Sip] = Requesting=20 feedback on draft-dotson-sip-certificate-auth-01

Some = industries=20 and organizations have invested in PKI, and thus have certificates = available=20 for authentication. We would like to leverage those credentials for = SIP=20 authentication. Using certificates instead of UICCs or other = credentials=20 is attractive for certain deployment models. http://www.ietf.org/internet-drafts/draft-dotson-sip-certifi= cate-auth-01.txt describes=20 some requirements related to this issue, as well as a review of = previous and=20 related work. We have received good feedback offline from authors = of=20 related work which were incorporated into the latest=20 draft.
 

Thanks,

 

Steve.

 

------_=_NextPart_001_01C70F17.9F7169D5-- --===============1203462367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1203462367==-- From sip-bounces@ietf.org Thu Nov 23 14:51:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKZx-0005wD-C4; Thu, 23 Nov 2006 14:49:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKZv-0005w2-I0 for sip@ietf.org; Thu, 23 Nov 2006 14:49:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnKZu-00017E-9I for sip@ietf.org; Thu, 23 Nov 2006 14:49:47 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2006 11:49:46 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kANJnjIX018549; Thu, 23 Nov 2006 11:49:45 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kANJnjio010703; Thu, 23 Nov 2006 11:49:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 11:49:45 -0800 Received: from [10.0.34.15] ([10.21.97.93]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 11:49:44 -0800 In-Reply-To: <953beacc0611211615g552f8847v6ec745749e741353@mail.gmail.com> References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF0E18B6AD@zrc2hxm0.corp.nortel.com> <953beacc0611211615g552f8847v6ec745749e741353@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Date: Thu, 23 Nov 2006 14:49:53 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Nov 2006 19:49:44.0645 (UTC) FILETIME=[86242750:01C70F38] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=350; t=1164311385; x=1165175385; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20strawman=20text=20for=20FASTEST=20proposal=20 in=20outbound |Sender:=20; bh=R1ov8bI0m3e/bSTKpLAMH5xKRZqHly2DJevJTXxodZI=; b=u2D3XrRWGxj6Wyz8+Jms0nMCUAj8Q+2Bi4uVCLUDfdkSvOCV2eSbYK2GW3Sf0Sl2yWilbLUH +A42FCvse7BquVXoLr+iMt2Gf3bA3v4BBqZLahtUifvdYw3Be77X20yZ; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: SIP WG , Rohan Mahy , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 21, 2006, at 7:15 PM, Rohan Mahy wrote: > I think we've already established that if a UA was going to bother > establishing a TCP or TLS flow that there would be no benefit to using > a UDP flow. Note I disagree that we have established this but I think it is more or less irrelevant to the discussion on what we should do here. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 23 15:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKsZ-00076w-Hs; Thu, 23 Nov 2006 15:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKsW-0006v3-0G; Thu, 23 Nov 2006 15:09:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnKp5-0002kA-Eg; Thu, 23 Nov 2006 15:05:28 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2006 12:05:26 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kANK5Qqm016415; Thu, 23 Nov 2006 12:05:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kANK5Qio016476; Thu, 23 Nov 2006 12:05:26 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:05:26 -0800 Received: from [10.0.34.15] ([10.21.98.32]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:05:25 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping , SIP From: Cullen Jennings Date: Thu, 23 Nov 2006 15:05:36 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Nov 2006 20:05:25.0924 (UTC) FILETIME=[B72FEE40:01C70F3A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=117; t=1164312326; x=1165176326; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Scheduling=20of=20Friday=20morning=20at=20next=20IETF |Sender:=20; bh=jmy2GsHNUjs+yVMHh5xAdxejiDMtzeTpH7n16S0GxAQ=; b=qsZgBa6hvhrp7i5XNhYYjkNnehntOwHgQ+j0zafire2J3RFCELI2UmCr5R9geYnEuIxyOp0F tnEHtdxPWeLBnFxSNc7qogCCScmbpWQnLBmSeTRAbZJuVpfNjnw/OFpH; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [Sip] Scheduling of Friday morning at next IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you are planning travel, there odds are good that there will be a sipping meeting Friday morning in Prague. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 06:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZ47-0006FT-F0; Fri, 24 Nov 2006 06:17:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZ46-0006CV-Ol for sip@ietf.org; Fri, 24 Nov 2006 06:17:54 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnZ41-0003QG-Bm for sip@ietf.org; Fri, 24 Nov 2006 06:17:52 -0500 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id kAOBHj09004398 for ; Fri, 24 Nov 2006 05:17:46 -0600 (CST) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Nov 2006 19:16:47 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Nov 2006 19:16:47 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Fri, 24 Nov 2006 19:16:47 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Multiplicity of SIP headers thread-index: AccO8/K6tmCI6NY1QH61UsLroxuH0QAATt/wADEnkbA= From: "Xia, Zhi Feng \(Bruce\)" To: "IETF SIP List" X-OriginalArrivalTime: 24 Nov 2006 11:16:47.0849 (UTC) FILETIME=[08278590:01C70FBA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] automatically switches to TCP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1105060206==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1105060206== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70FBA.07F54748" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70FBA.07F54748 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, There're many implementations when transportation on UDP fails or = transation timeout without response it will automatically try TCP = connection. Is this mandated in any RFCs? I think RFC3261 says if = transaction timeouts it should go to terminated state. =20 Is this implementation a violation to RFC3261? =20 Thanks, Bruce ------_=_NextPart_001_01C70FBA.07F54748 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
There're=20 many implementations when transportation on UDP fails or transation = timeout=20 without response it will automatically try TCP connection. Is this = mandated in=20 any RFCs? I think RFC3261 says if transaction timeouts it should go to=20 terminated state.
 
Is this=20 implementation a violation to RFC3261?
 
Thanks,
Bruce
------_=_NextPart_001_01C70FBA.07F54748-- --===============1105060206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1105060206==-- From sip-bounces@ietf.org Fri Nov 24 07:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZwW-0008Uq-6Q; Fri, 24 Nov 2006 07:14:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZwV-0008Ui-AA for sip@ietf.org; Fri, 24 Nov 2006 07:14:07 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnZwT-00013A-23 for sip@ietf.org; Fri, 24 Nov 2006 07:14:07 -0500 X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1164370430!6403840!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22431 invoked from network); 24 Nov 2006 12:13:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 24 Nov 2006 12:13:50 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kAOCDoff020487 for ; Fri, 24 Nov 2006 05:13:50 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id kAOCDmTR028441 for ; Fri, 24 Nov 2006 06:13:49 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Nov 2006 20:13:45 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA10154D211@ZMY16EXM67.ds.mot.com> In-Reply-To: <0J9600GTZFG6NU00@jes-fe1.zx.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: outbound-06: Question on TCP demultiplexing STUN and SIP traffic Thread-Index: AccO4dFgP+8DJ4QGSg6tOk76WABMEQA3N4PQ From: "Vavilapalli Srikanth-A19563" To: "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Section 8 of the draft says: For TCP or TLS over TCP flows, determining if the first octet of the next message in a stream is SIP or STUN is still straightforward. As with any stream-based protocol, implementations need to be prepared to receive STUN messages which cross a stream buffer boundary, and SIP and STUN messages which share the same stream buffer. Can anyone please elaborate more on demultiplexing of SIP and STUN message in case of TCP? If the STUN message is in middle of the read buffer, how can we demux these packets? Regards Srikanth _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 07:24:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gna5X-00059I-H8; Fri, 24 Nov 2006 07:23:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gna5W-000599-6l for sip@ietf.org; Fri, 24 Nov 2006 07:23:26 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gna5U-0001pR-Ro for sip@ietf.org; Fri, 24 Nov 2006 07:23:26 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id F1C723BF13; Fri, 24 Nov 2006 13:23:09 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05060-01-17; Fri, 24 Nov 2006 13:23:09 +0100 (CET) Received: from [193.11.30.14] (dhcp-wavelan-vo-14.publik.su.se [193.11.30.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 7F9FC3BF0F; Fri, 24 Nov 2006 13:23:09 +0100 (CET) Message-ID: <4566E416.7000800@it.su.se> Date: Fri, 24 Nov 2006 13:22:46 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vavilapalli Srikanth-A19563 Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic References: <608D7BFF0D57794785CBC2C440BC4FA10154D211@ZMY16EXM67.ds.mot.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA10154D211@ZMY16EXM67.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.649 tagged_above=-99 required=7 tests=[AWL=0.016, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vavilapalli Srikanth-A19563 wrote: ... > Can anyone please elaborate more on demultiplexing of SIP and STUN > message in case of TCP? If the STUN message is in middle of the read > buffer, how can we demux these packets? The STUN header (not sure that is the correct term) is fixed size - 20 bytes if I remember correctly. If you receive one byte that indicates this is STUN then you continue reading from the socket until you have received (at least) 19 more bytes. From the first 20 bytes you can figure out the total length of the STUN request. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 07:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaCC-0006QJ-GA; Fri, 24 Nov 2006 07:30:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaCB-0006QD-K2 for sip@ietf.org; Fri, 24 Nov 2006 07:30:19 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnaC7-0003CC-8y for sip@ietf.org; Fri, 24 Nov 2006 07:30:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIPtraffic Date: Fri, 24 Nov 2006 12:30:11 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23FFB@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: outbound-06: Question on TCP demultiplexing STUN and SIP traffic thread-index: AccO4dFgP+8DJ4QGSg6tOk76WABMEQA3N4PQAAF6+mA= From: "Attila Sipos" To: "Vavilapalli Srikanth-A19563" , "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 1. (obvious but) only look STUN response for it when you've sent a STUN request. 2. There is a STUN magic cookie (not in RFC3489 but in = http://www.heise.de/netze/rfc/drafts/draft-ietf-behave-rfc3489bis-05.shtm= l) 3. There is your transaction ID. Regards, Attila >> -----Original Message----- >> From: Vavilapalli Srikanth-A19563 [mailto:srikanthv@motorola.com] >> Sent: 24 November 2006 12:14 >> To: SIP WG >> Cc: Cullen Jennings; Rohan Mahy >> Subject: [Sip] outbound-06: Question on TCP demultiplexing STUN and >> SIPtraffic >>=20 >>=20 >> Hi >>=20 >> Section 8 of the draft says: For TCP or TLS over TCP flows,=20 >> determining >> if the first octet of the next message in a stream is SIP or STUN is >> still straightforward. As with any stream-based protocol, >> implementations need to be prepared to receive STUN messages=20 >> which cross >> a stream buffer boundary, and SIP and STUN messages which=20 >> share the same >> stream buffer. >>=20 >> Can anyone please elaborate more on demultiplexing of SIP and STUN >> message in case of TCP? If the STUN message is in middle of the read >> buffer, how can we demux these packets? >>=20 >> Regards >> Srikanth >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 07:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaDE-0000Am-KN; Fri, 24 Nov 2006 07:31:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaDE-0000Ah-3g for sip@ietf.org; Fri, 24 Nov 2006 07:31:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnaDA-0003OU-Ih for sip@ietf.org; Fri, 24 Nov 2006 07:31:24 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2006 04:31:20 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kAOCVJeD022844; Fri, 24 Nov 2006 04:31:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAOCVJdE003067; Fri, 24 Nov 2006 04:31:19 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 04:31:19 -0800 Received: from [10.0.35.231] ([10.21.144.45]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 04:31:19 -0800 In-Reply-To: <4566E416.7000800@it.su.se> References: <608D7BFF0D57794785CBC2C440BC4FA10154D211@ZMY16EXM67.ds.mot.com> <4566E416.7000800@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E6CE3CF-9DE2-4E49-BE5A-2A8F904BFF99@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Date: Fri, 24 Nov 2006 07:31:27 -0500 To: Fredrik Thulin X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 24 Nov 2006 12:31:19.0197 (UTC) FILETIME=[714914D0:01C70FC4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=999; t=1164371479; x=1165235479; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20outbound-06=3A=20Question=20on=20TCP=20demult iplexing=20STUN=20and=20SIP=20traffic |Sender:=20; bh=ALNk1V2qsRy3NeZBDYo8QZpy0dA/GWC8Dlm5Sk6tG48=; b=ZgZfPiS1zpia1GoOdhLJ6HKct2mDRQFq0qvRj2AlLKSFjEEkJ1p5nX2XovzJy3x2CtWkItsg HD2+WTeSCTIpfc9TanfvHx8vtI4L14YyAPxaWMK9lWY/jrlo3wIBwSTp; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not sure about the text in the draft is all clear but ... A STUN message can not occur in the middle of a SIP message and likewise you can not have a SIP in the middle of the STUN. The streams, the whole messages has to be inserted into the stream before starting a new message regardless of the type of the message. On Nov 24, 2006, at 7:22 AM, Fredrik Thulin wrote: > Vavilapalli Srikanth-A19563 wrote: > ... >> Can anyone please elaborate more on demultiplexing of SIP and STUN >> message in case of TCP? If the STUN message is in middle of the read >> buffer, how can we demux these packets? > > The STUN header (not sure that is the correct term) is fixed size - > 20 bytes if I remember correctly. > > If you receive one byte that indicates this is STUN then you > continue reading from the socket until you have received (at least) > 19 more bytes. From the first 20 bytes you can figure out the total > length of the STUN request. > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 07:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnaad-0006O8-2W; Fri, 24 Nov 2006 07:55:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnaab-0006NY-HV for sip@ietf.org; Fri, 24 Nov 2006 07:55:33 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gnaaa-000671-9r for sip@ietf.org; Fri, 24 Nov 2006 07:55:33 -0500 X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1164372929!10236674!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18669 invoked from network); 24 Nov 2006 12:55:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 24 Nov 2006 12:55:29 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kAOCtTMd026908 for ; Fri, 24 Nov 2006 05:55:29 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id kAOCtSah016181 for ; Fri, 24 Nov 2006 06:55:28 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Date: Fri, 24 Nov 2006 20:55:26 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA10154D22A@ZMY16EXM67.ds.mot.com> In-Reply-To: <9E6CE3CF-9DE2-4E49-BE5A-2A8F904BFF99@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Thread-Index: AccPxHx1MBg811nVR6CRqs/CAjGRtAAAv37Q From: "Vavilapalli Srikanth-A19563" To: "Cullen Jennings" , "Fredrik Thulin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for the confusion.=20 What I mean "in middle of the read buffer" is, For ex: In the first read I received a partial SIP message and in the next TCP read if I receive the remaining of the SIP message and followed by STUN message (in single read, and I believe this is possible in TCP communication), then demuxing will be difficult unless we parse the entire SIP message. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Friday, November 24, 2006 6:01 PM To: Fredrik Thulin Cc: Vavilapalli Srikanth-A19563; SIP WG; Rohan Mahy Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic I'm not sure about the text in the draft is all clear but ... A STUN message can not occur in the middle of a SIP message and likewise you can not have a SIP in the middle of the STUN. The streams, the whole messages has to be inserted into the stream before starting a new message regardless of the type of the message. On Nov 24, 2006, at 7:22 AM, Fredrik Thulin wrote: > Vavilapalli Srikanth-A19563 wrote: > ... >> Can anyone please elaborate more on demultiplexing of SIP and STUN=20 >> message in case of TCP? If the STUN message is in middle of the read=20 >> buffer, how can we demux these packets? > > The STUN header (not sure that is the correct term) is fixed size - 20 > From sip-bounces@ietf.org Fri Nov 24 07:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnaad-0006O8-2W; Fri, 24 Nov 2006 07:55:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnaab-0006NY-HV for sip@ietf.org; Fri, 24 Nov 2006 07:55:33 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gnaaa-000671-9r for sip@ietf.org; Fri, 24 Nov 2006 07:55:33 -0500 X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1164372929!10236674!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18669 invoked from network); 24 Nov 2006 12:55:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 24 Nov 2006 12:55:29 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kAOCtTMd026908 for ; Fri, 24 Nov 2006 05:55:29 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id kAOCtSah016181 for ; Fri, 24 Nov 2006 06:55:28 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Date: Fri, 24 Nov 2006 20:55:26 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA10154D22A@ZMY16EXM67.ds.mot.com> In-Reply-To: <9E6CE3CF-9DE2-4E49-BE5A-2A8F904BFF99@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Thread-Index: AccPxHx1MBg811nVR6CRqs/CAjGRtAAAv37Q From: "Vavilapalli Srikanth-A19563" To: "Cullen Jennings" , "Fredrik Thulin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for the confusion.=20 What I mean "in middle of the read buffer" is, For ex: In the first read I received a partial SIP message and in the next TCP read if I receive the remaining of the SIP message and followed by STUN message (in single read, and I believe this is possible in TCP communication), then demuxing will be difficult unless we parse the entire SIP message. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Friday, November 24, 2006 6:01 PM To: Fredrik Thulin Cc: Vavilapalli Srikanth-A19563; SIP WG; Rohan Mahy Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic I'm not sure about the text in the draft is all clear but ... A STUN message can not occur in the middle of a SIP message and likewise you can not have a SIP in the middle of the STUN. The streams, the whole messages has to be inserted into the stream before starting a new message regardless of the type of the message. On Nov 24, 2006, at 7:22 AM, Fredrik Thulin wrote: > Vavilapalli Srikanth-A19563 wrote: > ... >> Can anyone please elaborate more on demultiplexing of SIP and STUN=20 >> message in case of TCP? If the STUN message is in middle of the read=20 >> buffer, how can we demux these packets? > > The STUN header (not sure that is the correct term) is fixed size - 20 > bytes if I remember correctly. > > If you receive one byte that indicates this is STUN then you continue=20 > reading from the socket until you have received (at least) > 19 more bytes. From the first 20 bytes you can figure out the total=20 > length of the STUN request. > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 07:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaaY-0006IQ-1q; Fri, 24 Nov 2006 07:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaaW-0006Gr-43 for sip@ietf.org; Fri, 24 Nov 2006 07:55:28 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnaaS-00066C-E4 for sip@ietf.org; Fri, 24 Nov 2006 07:55:28 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAOCsuIF014493; Fri, 24 Nov 2006 14:55:06 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 14:54:57 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 14:54:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Proposal to split Outbound (was: [Sip] Re: issue with oubound and the used transport protocol) Date: Fri, 24 Nov 2006 14:54:57 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F030BA1F8@esebe103.NOE.Nokia.com> In-Reply-To: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Proposal to split Outbound (was: [Sip] Re: issue with oubound and the used transport protocol) Thread-Index: AccMvdVv5uMs1mHcRQaWY453swM2ugC78eSg From: To: , X-OriginalArrivalTime: 24 Nov 2006 12:54:57.0552 (UTC) FILETIME=[BEB0E100:01C70FC7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: fluffy@cisco.com, peter.leis@siemens.com, aki.niemi@nokia.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org CLEANEST I have two major reasons for this opinion: - After seeing the recent comments, the option to support UDP flows together with STUN keepalive really does not make sense. It is prone to fail with big enough messages, introduces a whole bunch of unnecessary complexity and further on is a burden for the battery consumption of mobile UAs (at least compared less frequent TCP keepalive). All practical examples of SIP use cases I have seen anyway generate messages exceeding 1300 bytes, for one purpose or another, sooner or later. - After having a look into separate drafts written for mid-dialog failover, I believe it would be a wrong decision to approve Outbound as soon as possible and leave this rather important mid-dialog case to be solved separately. It does not make sense to split the high availability features to two drafts: multiple registration to Outbound=20 and mid-dialog failover to some bytes if I remember correctly. > > If you receive one byte that indicates this is STUN then you continue=20 > reading from the socket until you have received (at least) > 19 more bytes. From the first 20 bytes you can figure out the total=20 > length of the STUN request. > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 07:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaaY-0006IQ-1q; Fri, 24 Nov 2006 07:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaaW-0006Gr-43 for sip@ietf.org; Fri, 24 Nov 2006 07:55:28 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnaaS-00066C-E4 for sip@ietf.org; Fri, 24 Nov 2006 07:55:28 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAOCsuIF014493; Fri, 24 Nov 2006 14:55:06 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 14:54:57 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 14:54:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Proposal to split Outbound (was: [Sip] Re: issue with oubound and the used transport protocol) Date: Fri, 24 Nov 2006 14:54:57 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F030BA1F8@esebe103.NOE.Nokia.com> In-Reply-To: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Proposal to split Outbound (was: [Sip] Re: issue with oubound and the used transport protocol) Thread-Index: AccMvdVv5uMs1mHcRQaWY453swM2ugC78eSg From: To: , X-OriginalArrivalTime: 24 Nov 2006 12:54:57.0552 (UTC) FILETIME=[BEB0E100:01C70FC7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: fluffy@cisco.com, peter.leis@siemens.com, aki.niemi@nokia.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org CLEANEST I have two major reasons for this opinion: - After seeing the recent comments, the option to support UDP flows together with STUN keepalive really does not make sense. It is prone to fail with big enough messages, introduces a whole bunch of unnecessary complexity and further on is a burden for the battery consumption of mobile UAs (at least compared less frequent TCP keepalive). All practical examples of SIP use cases I have seen anyway generate messages exceeding 1300 bytes, for one purpose or another, sooner or later. - After having a look into separate drafts written for mid-dialog failover, I believe it would be a wrong decision to approve Outbound as soon as possible and leave this rather important mid-dialog case to be solved separately. It does not make sense to split the high availability features to two drafts: multiple registration to Outbound=20 and mid-dialog failover to some other draft, especially when the failover draft is expected to have an impact to=20 Outbound. Instead the drafts should be combined the other way around. There should be one draft for outbound TCP connection maintenance and another for high availability by multiple registrations TOGETHER WITH mid-dialog failover. If a version of Outbound will be frozen with UDP support but without mid-dialog support, I believe there would either be no deployment for the specified features (UDP) or that the deployed implementations would lack those useful high availability features. For both cases: is there any point for speeding the process up=20 (even if there REALLY is an urgent need for these solutions)=20 if the result is that the agreed solution would not work well enough ? >Split outbound >c) outbound *connections* draft for TCP and TLS over TCP only.=20 >a) an update to Path that uses a reg-id to store multiple=20 >bindings/paths back to a UA regardless of transport. This is=20 >useful in the multiple radio interface use case for example=20 >even if there are no NATs. More or less this would be the right direction. However I still belive that the outbound connection draft could be the one specifying the Path handling. My proposal would be to move the reg-id and multiple registration part of Outbound to the mid-dialog failover draft. It has bothered me and my colleagues a long time that the Outbound draft has bundled together two different things that actually are orthogonal, both as problems and as solutions too. The only reason to keep them together in one single spec is that in some environments it makes sense to use them together, but the problem is that in some other environments separation would be desirable. Those two items could be described like this: - A mechanism with which an UA would be able to maintain a persistent flow through a NAT/firewall towards an outbound=20 proxy, keep the flow alive and monitor its state. The mechanism would also define how the authoritative and edge=20 proxies would use the persistent flow and Path header for=20 forwarding incoming requests to the UA. - A mechanism with which an UA instance would be able to achieve high availability towards its home domain, by maintaining multiple simultaneous registrations without the need to receive multiple forked copies of a single incoming request. This resiliency would enable the UA to protect its connectivity against edge proxy failures or access network connectivity=20 failures. This mechanism would introduce the reg-id parameter to Contact and allow the authoritative proxy to forward requests to the UA using the set of registered Contacts and corresponding Paths. The high availability draft should be able to refer to the outbound connections draft, so that depending on the case each of the multiple registrations might or might not set=20 up a persistent flow towards the outbound proxy. The high availability (including mid-dialog failover) mechanisms=20 should be specified so that they would work regardless of=20 whether the UA uses persistent connections towards edge=20 proxies or not. Of course persistent connections would be a must for NAT/firewall traversal, if that is the part of problem space in the specific environment. --- For those interested on the outbound TCP connections draft,=20 I made a small excercise today. Taking the normative text from=20 Outbound-06 as basis I put together normative sections for such a draft with the following features: 1. Replaced the reg-id parameter of Contact header with 'ob' URI=20 parameter to indicate the outbound connection support 2. Explicit support for multiple registration out of scope, but=20 possible to be specified within a separate draft 3. No support for UDP or STUN keepalives 4. Connection kept alive with TCP keepalive or CLRF I used this excercise as a proof-of-concept for myself that the separation could be done in a way straightforward enough. Please find the result below: 4. User Agent Mechanisms 4.1 Instance ID Creation [[ other draft, especially when the failover draft is expected to have an impact to=20 Outbound. Instead the drafts should be combined the other way around. There should be one draft for outbound TCP connection maintenance and another for high availability by multiple registrations TOGETHER WITH mid-dialog failover. If a version of Outbound will be frozen with UDP support but without mid-dialog support, I believe there would either be no deployment for the specified features (UDP) or that the deployed implementations would lack those useful high availability features. For both cases: is there any point for speeding the process up=20 (even if there REALLY is an urgent need for these solutions)=20 if the result is that the agreed solution would not work well enough ? >Split outbound >c) outbound *connections* draft for TCP and TLS over TCP only.=20 >a) an update to Path that uses a reg-id to store multiple=20 >bindings/paths back to a UA regardless of transport. This is=20 >useful in the multiple radio interface use case for example=20 >even if there are no NATs. More or less this would be the right direction. However I still belive that the outbound connection draft could be the one specifying the Path handling. My proposal would be to move the reg-id and multiple registration part of Outbound to the mid-dialog failover draft. It has bothered me and my colleagues a long time that the Outbound draft has bundled together two different things that actually are orthogonal, both as problems and as solutions too. The only reason to keep them together in one single spec is that in some environments it makes sense to use them together, but the problem is that in some other environments separation would be desirable. Those two items could be described like this: - A mechanism with which an UA would be able to maintain a persistent flow through a NAT/firewall towards an outbound=20 proxy, keep the flow alive and monitor its state. The mechanism would also define how the authoritative and edge=20 proxies would use the persistent flow and Path header for=20 forwarding incoming requests to the UA. - A mechanism with which an UA instance would be able to achieve high availability towards its home domain, by maintaining multiple simultaneous registrations without the need to receive multiple forked copies of a single incoming request. This resiliency would enable the UA to protect its connectivity against edge proxy failures or access network connectivity=20 failures. This mechanism would introduce the reg-id parameter to Contact and allow the authoritative proxy to forward requests to the UA using the set of registered Contacts and corresponding Paths. The high availability draft should be able to refer to the outbound connections draft, so that depending on the case each of the multiple registrations might or might not set=20 up a persistent flow towards the outbound proxy. The high availability (including mid-dialog failover) mechanisms=20 should be specified so that they would work regardless of=20 whether the UA uses persistent connections towards edge=20 proxies or not. Of course persistent connections would be a must for NAT/firewall traversal, if that is the part of problem space in the specific environment. --- For those interested on the outbound TCP connections draft,=20 I made a small excercise today. Taking the normative text from=20 Outbound-06 as basis I put together normative sections for such a draft with the following features: 1. Replaced the reg-id parameter of Contact header with 'ob' URI=20 parameter to indicate the outbound connection support 2. Explicit support for multiple registration out of scope, but=20 possible to be specified within a separate draft 3. No support for UDP or STUN keepalives 4. Connection kept alive with TCP keepalive or CLRF I used this excercise as a proof-of-concept for myself that the separation could be done in a way straightforward enough. Please find the result below: 4. User Agent Mechanisms 4.1 Instance ID Creation [[ As in Outbound-06, no changes needed ]] 4.2 Initial and Subsequent Registrations Registration requests, other than those described in Section 4.2.1, MUST include an instance-id media feature tag as specified in Section 4.1. Registration requests MUST also include the 'ob' URI parameter in the Contact URI. With 'ob' parameter the UA indicates that it wants to maintain a persistent flow towards the outbound proxy which receives the REGISTER request from the UA. The edge proxy is expected to use this flow when forwarding incoming requests towards the UA. UA MUST send the REGISTER request over a reliable transport protocol such as TCP. The connection over which the REGISTER was sent will be used as the persistent flow. The UA MUST not close the connection until it deregisters itself. Further on the UA must monitor the state of the flow and keep it alive as specified in section 4.4 of this specification. The UAC MUST indicate that it supports the Path header [RFC3327] mechanism, by including the 'path' option-tag in a Supported header field value in its REGISTER requests. Other than optionally examining the Path vector in the response, this is all that is required of the UAC to support Path. The UAC MAY examine successful registrations for the presence of an 'outbound' option-tag in a Supported header field value. Presence of this option-tag indicates that the registrar is compliant with this specification, and that any edge proxies which need to partcipate are also compliant. Finally, re-registrations which merely refresh an existing valid registration MUST be sent over the same flow as the original registration. 4.3 Sending Requests When a UA is about to send a request, it first performs normal processing to select the next hop URI. The UA can use a variety of techniques to compute the route set and accordingly the next hop URI. Discussion of these techniques is outside the scope of this document but could include mechanisms specified in RFC 3608 [RFC3608] (Service Route) and [I-D.rosenberg-sip-route-construct]. The UA performs normal DNS resolution on the next hop URI (as described in RFC 3263 [RFC3263]) to find a protocol, IP address, and port. For non-TLS protocols, if the UA has an existing flow to this IP address, and port with the correct protocol, then the UA MUST use the existing connection. For TLS protocols, there MUST also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate. If the UA cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol. Note that flows not created by registration will be closed when the related dialog is closed. While such a flow is open the UA SHOULD monitor its state and keep it alive by sending the keepalive messages. 4.4 Detecting Flow Failure The UA needs to detect when a specific flow fails. The UA actively tries to detect failure by periodically sending keepalive messages using one of the techniques described in Section 4.4.1. and =20 4.4.2. If a flow has failed, the UA follows the procedures in Section 4.2 to form a new flow to replace the failed one. The time between keepalive requests when using TCP- based transports SHOULD be a random number between 95 and 120 seconds. These times MAY be configurable. Issues such as battery consumption might motivate longer keepalive intervals. Note on selection of time values: For TCP, the 120 seconds upper bound was chosen based on the idea that for a good user experience, failures normally will be detected in this amount of time and a new connection set up. Operators that wish to change the relationship between load on servers and the expected time that a user might not receive inbound communications will probably adjustAs in Outbound-06, no changes needed ]] 4.2 Initial and Subsequent Registrations Registration requests, other than those described in Section 4.2.1, MUST include an instance-id media feature tag as specified in Section 4.1. Registration requests MUST also include the 'ob' URI parameter in the Contact URI. With 'ob' parameter the UA indicates that it wants to maintain a persistent flow towards the outbound proxy which receives the REGISTER request from the UA. The edge proxy is expected to use this flow when forwarding incoming requests towards the UA. UA MUST send the REGISTER request over a reliable transport protocol such as TCP. The connection over which the REGISTER was sent will be used as the persistent flow. The UA MUST not close the connection until it deregisters itself. Further on the UA must monitor the state of the flow and keep it alive as specified in section 4.4 of this specification. The UAC MUST indicate that it supports the Path header [RFC3327] mechanism, by including the 'path' option-tag in a Supported header field value in its REGISTER requests. Other than optionally examining the Path vector in the response, this is all that is required of the UAC to support Path. The UAC MAY examine successful registrations for the presence of an 'outbound' option-tag in a Supported header field value. Presence of this option-tag indicates that the registrar is compliant with this specification, and that any edge proxies which need to partcipate are also compliant. Finally, re-registrations which merely refresh an existing valid registration MUST be sent over the same flow as the original registration. 4.3 Sending Requests When a UA is about to send a request, it first performs normal processing to select the next hop URI. The UA can use a variety of techniques to compute the route set and accordingly the next hop URI. Discussion of these techniques is outside the scope of this document but could include mechanisms specified in RFC 3608 [RFC3608] (Service Route) and [I-D.rosenberg-sip-route-construct]. The UA performs normal DNS resolution on the next hop URI (as described in RFC 3263 [RFC3263]) to find a protocol, IP address, and port. For non-TLS protocols, if the UA has an existing flow to this IP address, and port with the correct protocol, then the UA MUST use the existing connection. For TLS protocols, there MUST also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate. If the UA cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol. Note that flows not created by registration will be closed when the related dialog is closed. While such a flow is open the UA SHOULD monitor its state and keep it alive by sending the keepalive messages. 4.4 Detecting Flow Failure The UA needs to detect when a specific flow fails. The UA actively tries to detect failure by periodically sending keepalive messages using one of the techniques described in Section 4.4.1. and =20 4.4.2. If a flow has failed, the UA follows the procedures in Section 4.2 to form a new flow to replace the failed one. The time between keepalive requests when using TCP- based transports SHOULD be a random number between 95 and 120 seconds. These times MAY be configurable. Issues such as battery consumption might motivate longer keepalive intervals. Note on selection of time values: For TCP, the 120 seconds upper bound was chosen based on the idea that for a good user experience, failures normally will be detected in this amount of time and a new connection set up. Operators that wish to change the relationship between load on servers and the expected time that a user might not receive inbound communications will probably adjust this time. The 95 seconds lower bound was chosen so that the jitter introduced will result in a relatively even load on the servers after 30 minutes. 4.4.1 Keepalive with TCP KEEPALIVE User Agents that are capable of generating per-connection TCP keepalives with timer values consistent with those in this section SHOULD use TCP keepalives for TCP-based flows. 4.4.2 Keepalive with CRLF User Agents that are not capable of generating per-connection TCP keeplalives with timer values consistent with those in this section or are using some other transport protocol than TCP SHOULD send CRLF sequences as keepalive messages. 4.4.3 Flow Recovery When a flow created during registration fails, the UA needs to form a new flow to replace the old flow and replace any registrations that were previously sent over this flow. This is done=20 in much the same way as forming a brand new flow as described in Section 4.2; however, if there is a failure in forming this flow, the UA needs to wait a certain amount of time before retrying to form a flow to this particular next hop. The amount of time to wait depends if the previous attempt at establishing a flow was successful. For the purposes of this section, a flow is considered successful if outbound registration succeeded and keepalives have not timed out for min-regtime seconds (default of 120 seconds) after a registration. If a flow is established and is alive after this amount of time, the number of consecutive registration failures is set to zero. Each time a flow fails before two minutes, the number of consecutive registration failures is incremented by one. =20 The number of seconds to wait is computed in the following way. This algorithm allows the UA to maintain multiple flows but it also applies even if the UA maintains one single flow towards its home proxy. Note that the techniques needed to maintain multiple flows are not in scope of this specification but may be defined within another document. If all of the flows to every URI in the outbound proxy set have failed, the base time is set to 30 seconds; otherwise, in the case where at least one of the flows has not failed, the base time is set to 90 seconds. The wait time is computed by taking two raised to the power of the number of consecutive registration failures for that URI, and multiplying this by the base time, up to a maximum of 1800 seconds. wait-time =3D min( max-time, (base-time * (2 ^ = consecutive-failures))) These times MAY be configurable in the UA. The four times are: o max-time with a default of 1800 seconds o base-time-all-fail with a default of 30 seconds o base-time-not-failed with a default of 90 seconds o min-regtime with a default of 120 seconds For example, if the base time is 30 seconds, and there were three failures, then the wait time is min(1800,30*(2^3)) or 240 seconds. The delay time is computed by selecting a uniform random time between 50 and 100 percent of the wait time. The UA MUST wait for the value of the delay time before trying another registration to form a new flow for that URI. To be explicitly clear on the boundary conditions: when the UA boots it immediately tries to register. If this fails and no registration on other flows succeed, the first retry happens somewhere between 30 and 60 seconds after the failure of the first registration request. If the number of consecutive-failures is large enough that the maximum of 1800 seconds is reached, the UA will keep trying indefinitely with a random time of 15 to 30 minutes (900 to 1800 seconds) between each attempt. 5. Edge Proxy Mechanisms 5.1 Processing Register Requests When an Edge Proxy receives a registration request with a 'ob' URI parameter in the Contact URI, it needs to determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the user agent identified in the Contact header field, or no this time. The 95 seconds lower bound was chosen so that the jitter introduced will result in a relatively even load on the servers after 30 minutes. 4.4.1 Keepalive with TCP KEEPALIVE User Agents that are capable of generating per-connection TCP keepalives with timer values consistent with those in this section SHOULD use TCP keepalives for TCP-based flows. 4.4.2 Keepalive with CRLF User Agents that are not capable of generating per-connection TCP keeplalives with timer values consistent with those in this section or are using some other transport protocol than TCP SHOULD send CRLF sequences as keepalive messages. 4.4.3 Flow Recovery When a flow created during registration fails, the UA needs to form a new flow to replace the old flow and replace any registrations that were previously sent over this flow. This is done=20 in much the same way as forming a brand new flow as described in Section 4.2; however, if there is a failure in forming this flow, the UA needs to wait a certain amount of time before retrying to form a flow to this particular next hop. The amount of time to wait depends if the previous attempt at establishing a flow was successful. For the purposes of this section, a flow is considered successful if outbound registration succeeded and keepalives have not timed out for min-regtime seconds (default of 120 seconds) after a registration. If a flow is established and is alive after this amount of time, the number of consecutive registration failures is set to zero. Each time a flow fails before two minutes, the number of consecutive registration failures is incremented by one. =20 The number of seconds to wait is computed in the following way. This algorithm allows the UA to maintain multiple flows but it also applies even if the UA maintains one single flow towards its home proxy. Note that the techniques needed to maintain multiple flows are not in scope of this specification but may be defined within another document. If all of the flows to every URI in the outbound proxy set have failed, the base time is set to 30 seconds; otherwise, in the case where at least one of the flows has not failed, the base time is set to 90 seconds. The wait time is computed by taking two raised to the power of the number of consecutive registration failures for that URI, and multiplying this by the base time, up to a maximum of 1800 seconds. wait-time =3D min( max-time, (base-time * (2 ^ = consecutive-failures))) These times MAY be configurable in the UA. The four times are: o max-time with a default of 1800 seconds o base-time-all-fail with a default of 30 seconds o base-time-not-failed with a default of 90 seconds o min-regtime with a default of 120 seconds For example, if the base time is 30 seconds, and there were three failures, then the wait time is min(1800,30*(2^3)) or 240 seconds. The delay time is computed by selecting a uniform random time between 50 and 100 percent of the wait time. The UA MUST wait for the value of the delay time before trying another registration to form a new flow for that URI. To be explicitly clear on the boundary conditions: when the UA boots it immediately tries to register. If this fails and no registration on other flows succeed, the first retry happens somewhere between 30 and 60 seconds after the failure of the first registration request. If the number of consecutive-failures is large enough that the maximum of 1800 seconds is reached, the UA will keep trying indefinitely with a random time of 15 to 30 minutes (900 to 1800 seconds) between each attempt. 5. Edge Proxy Mechanisms 5.1 Processing Register Requests When an Edge Proxy receives a registration request with a 'ob' URI parameter in the Contact URI, it needs to determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the user agent identified in the Contact header field, or not. If the Edge Proxy determines that this is the case, it inserts its URI in a Path header field value as described in RFC 3327 [RFC3327]. If the Edge Proxy is the first SIP node after the UAC, it either MUST store a "flow token"--containing information about the flow from the previous hop--in its Path URI, or reject the request. The flow token MAY be placed in the userpart of the URI. In addition, the first node MUST include an 'ob' URI parameter in its Path header field value. If the Edge Proxy is not the first SIP node after the UAC it MUST NOT place an 'ob' URI parameter in a Path header field value. The Edge Proxy can determine if it is the first hop by examining the Via header field 5.2 Generating Flow Tokens [[ As in Outbound-06, no changes needed ]] 5.3 Forwarding Requests When an Edge Proxy receives a request, it applies normal routing procedures with the following addition. If the Edge Proxy receives a request where the edge proxy is the host in the topmost Route header field value, and the Route header contains a flow token, the proxy compares the flow in the flow token with the source of the request. If these refer to the same flow, the Edge Proxy removes the Route header and continues processing the request. Otherwise, if the top- most Route header refers to the Edge Proxy and contains a valid flow identifier token created by this proxy, the proxy MUST remove the Route header and forward the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance. For connection-oriented transports, if the flow no longer exists the proxy SHOULD send a 430 (Flow Failed) response to the request. The advantage to a stateless approach to managing the flow information is that there is no state on the Edge Proxy that requires clean up or that has to be synchronized with the registrar. Proxies which used one of the two algorithms described in this document to form a flow token follow the procedures below to determine the correct flow. Algorithm 1: The proxy base64 decodes the user part of the Route header. For a TCP-based transport, if a connection specified by the file descriptor is present and the creation time of the file descriptor matches the creation time encoded in the Route header, the proxy forwards the request over that connection. For a UDP- based transport, the proxy forwards the request from the encoded file descriptor to the source IP address and port. Algorithm 2: To decode the flow token, take the flow identifier in the user portion of the URI and base64 decode it, then verify the HMAC is correct by recomputing the HMAC and checking it matches. If the HMAC is not correct, the proxy SHOULD send a 403 (Forbidden) response. If the HMAC is correct then the proxy SHOULD forward the request on the flow that was specified by the information in the flow identifier. If this flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request. 6. Registrar Mechanisms: Processing REGISTER Requests This specification updates the definition of a binding in RFC 3261 [RFC3261] Section 10 and RFC 3327 [RFC3327] Section 5.3. When the Contact of REGISTER request contains an 'ob' URI parameter and +sip.instance media feature parameter, the corresponding binding is between an AOR and the the instance-id (from the=20 +sip.instance media feature parameter). For such a binding with 'ob' URI parameter, the registrar still stores the Contact header field value URI with the binding, but does not consider the Contact URI for comparison purposes. If the Contact of REGISTER request contains an 'ob' URI parameter but not any +sip.instance media feature parameter, the registrar simply ignores the 'ob' parameter. The registrar MUST=20 be prepared to receive, simultaneously for the same AOR, some regit. If the Edge Proxy determines that this is the case, it inserts its URI in a Path header field value as described in RFC 3327 [RFC3327]. If the Edge Proxy is the first SIP node after the UAC, it either MUST store a "flow token"--containing information about the flow from the previous hop--in its Path URI, or reject the request. The flow token MAY be placed in the userpart of the URI. In addition, the first node MUST include an 'ob' URI parameter in its Path header field value. If the Edge Proxy is not the first SIP node after the UAC it MUST NOT place an 'ob' URI parameter in a Path header field value. The Edge Proxy can determine if it is the first hop by examining the Via header field 5.2 Generating Flow Tokens [[ As in Outbound-06, no changes needed ]] 5.3 Forwarding Requests When an Edge Proxy receives a request, it applies normal routing procedures with the following addition. If the Edge Proxy receives a request where the edge proxy is the host in the topmost Route header field value, and the Route header contains a flow token, the proxy compares the flow in the flow token with the source of the request. If these refer to the same flow, the Edge Proxy removes the Route header and continues processing the request. Otherwise, if the top- most Route header refers to the Edge Proxy and contains a valid flow identifier token created by this proxy, the proxy MUST remove the Route header and forward the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance. For connection-oriented transports, if the flow no longer exists the proxy SHOULD send a 430 (Flow Failed) response to the request. The advantage to a stateless approach to managing the flow information is that there is no state on the Edge Proxy that requires clean up or that has to be synchronized with the registrar. Proxies which used one of the two algorithms described in this document to form a flow token follow the procedures below to determine the correct flow. Algorithm 1: The proxy base64 decodes the user part of the Route header. For a TCP-based transport, if a connection specified by the file descriptor is present and the creation time of the file descriptor matches the creation time encoded in the Route header, the proxy forwards the request over that connection. For a UDP- based transport, the proxy forwards the request from the encoded file descriptor to the source IP address and port. Algorithm 2: To decode the flow token, take the flow identifier in the user portion of the URI and base64 decode it, then verify the HMAC is correct by recomputing the HMAC and checking it matches. If the HMAC is not correct, the proxy SHOULD send a 403 (Forbidden) response. If the HMAC is correct then the proxy SHOULD forward the request on the flow that was specified by the information in the flow identifier. If this flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request. 6. Registrar Mechanisms: Processing REGISTER Requests This specification updates the definition of a binding in RFC 3261 [RFC3261] Section 10 and RFC 3327 [RFC3327] Section 5.3. When the Contact of REGISTER request contains an 'ob' URI parameter and +sip.instance media feature parameter, the corresponding binding is between an AOR and the the instance-id (from the=20 +sip.instance media feature parameter). For such a binding with 'ob' URI parameter, the registrar still stores the Contact header field value URI with the binding, but does not consider the Contact URI for comparison purposes. If the Contact of REGISTER request contains an 'ob' URI parameter but not any +sip.instance media feature parameter, the registrar simply ignores the 'ob' parameter. The registrar MUST=20 be prepared to receive, simultaneously for the same AOR, some registrations that use instance-id and 'ob' and some registrations=20 that do not. Registrars which implement this specification MUST support the Path header mechanism [RFC3327]. In addition to the normal information stored in the binding record, some additional information needs to be stored for any registration that contains an instance-id header parameter and a 'ob' URI parameter in the Contact header field value. First the registrar examines the first Path header field value, if any. If the Path header field exists and the first URI does not have an 'ob' URI parameter, the registrar MUST ignore the 'ob' parameter in Contact and continue processing the request as if it did not support this specification. Likewise if the REGISTER request visited an edge proxy, but no Path header field values are present, the registrar MUST ignore the 'ob' parameter in Contact URI. Specifically, the registrar MUST use RFC 3261 Contact binding rules, and MUST NOT include the 'outbound' option-tag in its Supported header field. The registrar can determine if it is the first hop by examining the Via header field. If the UAC has a direct flow with the registrar, the registrar MUST store enough information to uniquely identify the network flow over which the request arrived. For common operating systems with TCP, this would typically just be the file descriptor and the time the file descriptor was opened. For common operating systems with UDP this would typically be the file descriptor for the local socket that received the request, the local interface, and the IP address and port number of the remote side that sent the request. The registrar MAY store this information by adding itself to the Path header field with an appropriate flow token. The registrar MUST also store all the Contact header field information including the instance-id parameter and SHOULD also store the time at which the binding was last updated. If a Path header field is present, RFC 3327 [RFC3327] requires the registrar to store this information as well. If the registrar receives a re-registration, it MUST update any information that uniquely identifies the network flow over which the request arrived if that information has changed, and SHOULD update the time the binding was last updated. The Registrar MUST include the 'outbound' option-tag (defined in Section (Section 12.1)) in a Supported header field value in its responses to REGISTER requests for which it has performed outbound processing. The Registrar MAY be configured with local policy to reject any registrations that do not include the instance-id and 'ob'. Note that the requirements in this section applies to both REGISTER requests received from an Edge Proxy as well as requests received directly from the UAC. To be compliant with this specification, registrars which can receive SIP requests directly from a UAC without intervening edge proxies MUST implement the STUN NAT Keepalive usage on its SIP ports as described in Section 8. 7. Authoritative Proxy Mechansims: Forwarding Requests When a proxy uses the location service to look up a registration binding and then proxies a request to a particular contact, it selects a contact to use normally, with a few additional rules: o The proxy MUST NOT populate the target set with more than one contact with the same AOR and instance-id at a time. If a request for a particular AOR and instance-id fails with a 430 (Flow Failed) response, the proxy SHOULD replace the failed branch with another target (if one is available) with the same AOR and instance-id, but for different flow, if available. o If the proxy receives a final response from a branch other than a 408 (Request Timeout) or a 430 (Flow Failed) response, the proxy MUST NOT forward the same request to another target representing the same AOR and instance-id. The targetted instance has already strations that use instance-id and 'ob' and some registrations=20 that do not. Registrars which implement this specification MUST support the Path header mechanism [RFC3327]. In addition to the normal information stored in the binding record, some additional information needs to be stored for any registration that contains an instance-id header parameter and a 'ob' URI parameter in the Contact header field value. First the registrar examines the first Path header field value, if any. If the Path header field exists and the first URI does not have an 'ob' URI parameter, the registrar MUST ignore the 'ob' parameter in Contact and continue processing the request as if it did not support this specification. Likewise if the REGISTER request visited an edge proxy, but no Path header field values are present, the registrar MUST ignore the 'ob' parameter in Contact URI. Specifically, the registrar MUST use RFC 3261 Contact binding rules, and MUST NOT include the 'outbound' option-tag in its Supported header field. The registrar can determine if it is the first hop by examining the Via header field. If the UAC has a direct flow with the registrar, the registrar MUST store enough information to uniquely identify the network flow over which the request arrived. For common operating systems with TCP, this would typically just be the file descriptor and the time the file descriptor was opened. For common operating systems with UDP this would typically be the file descriptor for the local socket that received the request, the local interface, and the IP address and port number of the remote side that sent the request. The registrar MAY store this information by adding itself to the Path header field with an appropriate flow token. The registrar MUST also store all the Contact header field information including the instance-id parameter and SHOULD also store the time at which the binding was last updated. If a Path header field is present, RFC 3327 [RFC3327] requires the registrar to store this information as well. If the registrar receives a re-registration, it MUST update any information that uniquely identifies the network flow over which the request arrived if that information has changed, and SHOULD update the time the binding was last updated. The Registrar MUST include the 'outbound' option-tag (defined in Section (Section 12.1)) in a Supported header field value in its responses to REGISTER requests for which it has performed outbound processing. The Registrar MAY be configured with local policy to reject any registrations that do not include the instance-id and 'ob'. Note that the requirements in this section applies to both REGISTER requests received from an Edge Proxy as well as requests received directly from the UAC. To be compliant with this specification, registrars which can receive SIP requests directly from a UAC without intervening edge proxies MUST implement the STUN NAT Keepalive usage on its SIP ports as described in Section 8. 7. Authoritative Proxy Mechansims: Forwarding Requests When a proxy uses the location service to look up a registration binding and then proxies a request to a particular contact, it selects a contact to use normally, with a few additional rules: o The proxy MUST NOT populate the target set with more than one contact with the same AOR and instance-id at a time. If a request for a particular AOR and instance-id fails with a 430 (Flow Failed) response, the proxy SHOULD replace the failed branch with another target (if one is available) with the same AOR and instance-id, but for different flow, if available. o If the proxy receives a final response from a branch other than a 408 (Request Timeout) or a 430 (Flow Failed) response, the proxy MUST NOT forward the same request to another target representing the same AOR and instance-id. The targetted instance has already provided its response. The proxy uses normal forwarding rules looking at the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward the request and populate the Route header in the request. If the proxy stored information about the flow over which it received the REGISTER for the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding that is known to deliver data to the specific target UA instance. Typically this means that for TCP, the request is sent on the same TCP socket that received the REGISTER request. =20 If a proxy or registrar receives information from the network that indicates that no future messages will be delivered on a specific flow, then the proxy MUST invalidate all the bindings in the target set that use that flow (regardless of AOR). Examples of this are a TCP socket closing. Similarly, if a proxy closes a file descriptor, it MUST invalidate all the bindings in the target set with flows that use that file descriptor. Combining the multiple registration part of Outbound-06 together with one of the mid-dialog failover drafts would be a bigger excercise, so I skipped that for now ;-) Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip provided its response. The proxy uses normal forwarding rules looking at the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward the request and populate the Route header in the request. If the proxy stored information about the flow over which it received the REGISTER for the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding that is known to deliver data to the specific target UA instance. Typically this means that for TCP, the request is sent on the same TCP socket that received the REGISTER request. =20 If a proxy or registrar receives information from the network that indicates that no future messages will be delivered on a specific flow, then the proxy MUST invalidate all the bindings in the target set that use that flow (regardless of AOR). Examples of this are a TCP socket closing. Similarly, if a proxy closes a file descriptor, it MUST invalidate all the bindings in the target set with flows that use that file descriptor. Combining the multiple registration part of Outbound-06 together with one of the mid-dialog failover drafts would be a bigger excercise, so I skipped that for now ;-) Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 08:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnato-0001CU-3S; Fri, 24 Nov 2006 08:15:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnatg-000133-Dh for sip@ietf.org; Fri, 24 Nov 2006 08:15:16 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnarB-0008Nx-05 for sip@ietf.org; Fri, 24 Nov 2006 08:12:42 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 372363BF03; Fri, 24 Nov 2006 14:12:30 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09663-01-28; Fri, 24 Nov 2006 14:12:29 +0100 (CET) Received: from [193.11.30.14] (dhcp-wavelan-vo-14.publik.su.se [193.11.30.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id B4A173BE4B; Fri, 24 Nov 2006 14:12:29 +0100 (CET) Message-ID: <4566EFA7.3000106@it.su.se> Date: Fri, 24 Nov 2006 14:12:07 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vavilapalli Srikanth-A19563 Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic References: <608D7BFF0D57794785CBC2C440BC4FA10154D22A@ZMY16EXM67.ds.mot.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA10154D22A@ZMY16EXM67.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.649 tagged_above=-99 required=7 tests=[AWL=0.016, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cullen Jennings , SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vavilapalli Srikanth-A19563 wrote: > Sorry for the confusion. > > What I mean "in middle of the read buffer" is, For ex: In the first read > I received a partial SIP message and in the next TCP read if I receive > the remaining of the SIP message and followed by STUN message (in single > read, and I believe this is possible in TCP communication), then > demuxing will be difficult unless we parse the entire SIP message. No, demuxing will be _impossible_ unless you parse the entire SIP message first. I can't think of a single reason why one would not want to parse the complete SIP message first, can you please explain? /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 10:09:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gncf2-0006aT-AS; Fri, 24 Nov 2006 10:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gncez-0006aO-7y for sip@ietf.org; Fri, 24 Nov 2006 10:08:13 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gncex-00018y-07 for sip@ietf.org; Fri, 24 Nov 2006 10:08:13 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9800DT1Q00XL@szxga01-in.huawei.com> for sip@ietf.org; Fri, 24 Nov 2006 23:07:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9800MD7Q004O@szxga01-in.huawei.com> for sip@ietf.org; Fri, 24 Nov 2006 23:07:12 +0800 (CST) Received: from manjunath ([10.18.8.69]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9800L5UPZVV7@szxml04-in.huawei.com> for sip@ietf.org; Fri, 24 Nov 2006 23:07:12 +0800 (CST) Date: Fri, 24 Nov 2006 20:37:07 +0530 From: Manjunath Warad Subject: RE: [Sip] automatically switches to TCP In-reply-to: To: "'Xia, Zhi Feng (Bruce)'" , 'IETF SIP List' Message-id: <000001c70fda$35dc5db0$4508120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook 11 Thread-index: AccO8/K6tmCI6NY1QH61UsLroxuH0QAATt/wADEnkbAAB//hMA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manjunathwarad@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1847079792==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1847079792== Content-type: multipart/alternative; boundary="Boundary_(ID_bauwvnWgR+NGAeCDLVd8JA)" This is a multi-part message in MIME format. --Boundary_(ID_bauwvnWgR+NGAeCDLVd8JA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Bruce, I think this is other way round, if sending on TCP fails then it is recommended to try on UDP to keep the backward compatibility with RFC 2543. After timeout transaction MUST enter into terminated state and will not retry by changing the protocol. Regards, Manju **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com] Sent: Friday, November 24, 2006 4:47 PM To: IETF SIP List Subject: [Sip] automatically switches to TCP Hi, There're many implementations when transportation on UDP fails or transation timeout without response it will automatically try TCP connection. Is this mandated in any RFCs? I think RFC3261 says if transaction timeouts it should go to terminated state. Is this implementation a violation to RFC3261? Thanks, Bruce --Boundary_(ID_bauwvnWgR+NGAeCDLVd8JA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi Bruce,
    I think this is other way round, if sending on TCP fails then it is recommended to try on UDP to keep the backward compatibility with RFC 2543.
After timeout transaction MUST enter into terminated state and will not retry by changing the protocol.
 
Regards,
Manju
 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com]
Sent: Friday, November 24, 2006 4:47 PM
To: IETF SIP List
Subject: [Sip] automatically switches to TCP

Hi,
There're many implementations when transportation on UDP fails or transation timeout without response it will automatically try TCP connection. Is this mandated in any RFCs? I think RFC3261 says if transaction timeouts it should go to terminated state.
 
Is this implementation a violation to RFC3261?
 
Thanks,
Bruce
--Boundary_(ID_bauwvnWgR+NGAeCDLVd8JA)-- --===============1847079792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1847079792==-- From sip-bounces@ietf.org Fri Nov 24 16:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GniEU-0002jo-Uf; Fri, 24 Nov 2006 16:05:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GniET-0002jh-5Z for sip@ietf.org; Fri, 24 Nov 2006 16:05:13 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GniEM-0007nd-LY for sip@ietf.org; Fri, 24 Nov 2006 16:05:13 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kAOL4lYP027045; Fri, 24 Nov 2006 15:04:47 -0600 (CST) Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 15:04:47 -0600 Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 15:04:46 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 22:04:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Nov 2006 22:04:43 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918088431F@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sip-gruu-11 Thread-Index: AccQDCobe4M/BAhESx6Belg8We3Olw== From: "Drage, Keith \(Keith\)" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 24 Nov 2006 21:04:44.0420 (UTC) FILETIME=[2AA11440:01C7100C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: rohan@ekabal.com Subject: [Sip] Comments on draft-ietf-sip-gruu-11 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My comments as follows (as you can see I have found nothing particularly major in the document that requires correction). I have also sent some NITs direct to the editor. 1) This is really a NIT, but as it involves two documents I will raise it on the list. We need to get the textual usages of the instance id parameter consistent between draft-ietf-sip-gruu and draft-ietf-sip-outbound. draft-ietf-sip-gruu seems to mainly call it a: "+sip.instance" parameter in the Contact header field "+sip.instance" Contact header field parameter But I note at least instances of "sip.instance" media feature tag [14] as a UA characteristic [7] "+sip.instance" header field parameter For exactly the same thing. In draft-ietf-sip-outbound (-06 to appear) we have the following: "sip.instance" media feature tag as a UA characteristic [RFC3840] the Contact header field as the "+sip.instance" Contact header field parameter sip.instance media feature tag the +sip.instance Contact header field parameter an instance-id media feature tag=20 +sip.instance media feature parameter is present in a Contact header field value=20 Can Jonathan and Rohan work together to agree a common and consistent usage. 2) Again, a NIT, but the same thing. In both documents can we also use "UA instance" rather than just "instance". Mostly consistent, but a few exceptions. In outbound there is also a "SIP UA instance" where I think the "SIP" is unnecessary. Can Jonathan and Rohan work together to agree a common and consistent usage. 3) Again a NIT but the same thing. "Instance ID" is used throughout in draft-ietf-sip-gruu. In draft-ietf-sip-outbound we have the following definition: instance-id: This specification uses the word instance-id to refer to the value of the "sip.instance" media feature tag in the Contact header field. This is a Uniform Resource Name (URN) that uniquely identifies this specific UA instance. Followed by usage of that term throughout the document...except: Title 4.1: "Instance ID Creation" and also within the contents of same section. Can Jonathan and Rohan work together to agree a common and consistent usage. 4) In section 4.1 we have: The contact URI MUST NOT be equivalent, based on the URI equality rules in RFC 3261, to the AOR in the To header field. I was trying to work out why this was a normative requirement of the GRUU document, given that it is followed by: If the contact URI is a GRUU, it MUST NOT be a GRUU for the AOR in the To header field. Which is the normative statement within the scope of GRUU, is the first statement really normative (with a MUST). 5) Again a NIT, but can we please use RFC numbers in the references. I know what you have done is allowed in the rules, but I get fed up trying to remember that [14] is outbound. It is, isn't it? 6) Section 5.1, current text is: Next, the registrar SHOULD create a new temporary GRUU for the AOR and instance ID with the characteristics described in Section 5.4. The temporary GRUU construction algorithm MUST have the following two properties: 1. The likelihood that the temporary GRUU is equal to another GRUU which the registrar has created MUST be vanishingly small. 2. Given a pair of GRUUs, it MUST be computationally infeasible to determine whether they were issued for the same AOR or instance ID or different AORs and instance IDs. I would prefer to make this a registrar requirement by rephrasing the text in the following manner. Also the MUSTs in 1) and 2) are not necessary because they are part of the first MUST in the main text. Next, the registrar SHOULD create a new temporary GRUU for the AOR and instance ID with the characteristics described in Section 5.4. The registrar MUST apply a temporary GRUU construction algorithm=20 with the following two properties: 1. The likelihood that the temporary GRUU is equal to another GRUU which the registrar has created is vanishingly small. 2. Given a pair of GRUUs, it is computationally infeasible to determine whether they were issued for the same AOR or instance ID or different AORs and instance IDs. 7) Section 5.3: If, as a consequence of the expiration of the contact, a particular GRUU no longer has any registered contacts bound to it, and the GRUU is a temporary GRUU, the GRUU MUST be destroyed. =20 Change to: If, as a consequence of the expiration of the contact, a particular GRUU no longer has any registered contacts bound to it, and the GRUU is a temporary GRUU, the registrar MUST destroyed the GRUU.=20 I assume the above is a registrar requirement but the current text does not seem particularly clear in that regard. 8) Section 5.4: When a registrar creates a GRUU, it is required to maintain certain information associated with the GRUU, regardless of whether it is a public or temporary GRUU. Every GRUU is associated with a single AOR and a single instance ID. A registrar MUST be able to determine the instance ID and AOR when presented with a GRUU. I think the "MUST" is in the wrong place here. We need a wording that is more like: Every GRUU is associated with a single AOR and a single instance ID.=20 When a registrar creates a GRUU, a registrar MUST maintain certain=20 information associated with a GRUU, regardless of whether it is a public or temporary GRUU, such that it=20 can determine the instance ID and AOR when presented with a GRUU." 9) Section 5.4: There can be multiple GRUUs with the same instance ID and AOR. Indeed, this specification requires registrars to maintain many - one that is public, and several that are temporary. However, if two GRUUs are associated with different AOR or different instance IDs or both, the GRUUs MUST be different based on URI equality comparison. A GRUU in a domain MUST NOT be equivalent, based on URI comparison, to any AOR in a domain except for the one associated with the GRUU. Again I think we have lost the MUST requirement here. Surely the requirement is that "A registrar MUST create GRUUs" that fulfil these rules. 10) Section 5.4: This specification does not mandate a particular mechanism for construction of the GRUU. Several example approaches are given in Appendix A. However, in addition to the properties described in Section 3.1, a GRUU constructed by a registrar MUST exhibit the following properties: Again I think this needs to be rephrased as a registrar requirement. Change to: This specification does not mandate a particular mechanism for construction of the GRUU. Several example approaches are given in Appendix A. However, in addition to the properties described in Section 3.1, a registrar MUST construct a GRUU such that it exhibits the following properties: 11) I note the following text in section 5.3: If, however, the GRUU was a public GRUU, the registrar SHOULD continue to treat the GRUU as valid. Consequently, subsequent requests targeted to the GRUU, prior to re-registration of a contact to the GRUU, SHOULD return a 480. In addition, since the GRUU remains valid, the rules in Section 5.1 will cause it to be retained when a contact with that instance ID is once again registered to the AOR. And the following in section 6.1: If there are no registered contacts bound to the GRUU, the server MUST return a 480. If there are more than one, the rules described in Section 7 of [14] for selecting a single registered contact apply. Any caller preferences in the request [19] SHOULD be processed against the contacts bound to the GRUU. It appears to me that one requirement (6.1) is a more generic requirement of the other, and as it is a MUST strength, the former one is not valid at SHOULD strength. 12) Section 7: The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI. However, they are encoded like all other quoted strings and can therefore contain quoted-pair escapes when represented this way. I am not keen on writing MUSTs in grammer sections in this manner as I am never sure if it is a sender or receiver requirement. It appears to me that we have a requirement elsewhere in the document that says (section 5.1): If the contact is not a SIP URI, the REGISTER request MUST be rejected with a 403. Therefore I assume the only requirement here is one for the UA generating GRUUs. Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Nov 24 20:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnmGS-000369-19; Fri, 24 Nov 2006 20:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnmGQ-00035z-ET for sip@ietf.org; Fri, 24 Nov 2006 20:23:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnmGN-0006Ik-3K for sip@ietf.org; Fri, 24 Nov 2006 20:23:30 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2006 17:23:26 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAP1NQle030073; Fri, 24 Nov 2006 17:23:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAP1NKdE016913; Fri, 24 Nov 2006 17:23:20 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 17:23:20 -0800 Received: from [192.168.1.3] ([10.21.122.20]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 17:23:19 -0800 In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA10154D22A@ZMY16EXM67.ds.mot.com> References: <608D7BFF0D57794785CBC2C440BC4FA10154D22A@ZMY16EXM67.ds.mot.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66A39903-B29E-420B-AE14-3281330512CC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Date: Fri, 24 Nov 2006 17:23:23 -0800 To: Vavilapalli Srikanth-A19563 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Nov 2006 01:23:19.0989 (UTC) FILETIME=[4AA10650:01C71030] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2095; t=1164417806; x=1165281806; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20outbound-06=3A=20Question=20on=20TCP=20demult iplexing=20STUN=20and=20SIP=20traffic |Sender:=20; bh=8UJAIeyT4fCasCFQeptPAB/okYeANLpjwCfA/u1W+VY=; b=NsFRHCJ5XWLw2jtwY7ZyI/DuxLfepXGeUgQW13T+DhJcd5FASbuNcE4gWhUWRG17sNg/8ykF uOJ1C7djwWDahAQSw/XfQyDOJCKpZo7hsy3fiJ9rKUMAisVOsyv9B8Lj; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: SIP WG , Rohan Mahy , Fredrik Thulin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You have the same problem reading two sip messages in a row. Many implementations have e a simple state machine that scans past the headers, find the content length, then scan past the body but no parsing other than that. I can point you at some code if you want. On Nov 24, 2006, at 4:55 AM, Vavilapalli Srikanth-A19563 wrote: > Sorry for the confusion. > > What I mean "in middle of the read buffer" is, For ex: In the first > read > I received a partial SIP message and in the next TCP read if I receive > the remaining of the SIP message and followed by STUN message (in > single > read, and I believe this is possible in TCP communication), then > demuxing will be difficult unless we parse the entire SIP message. > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, November 24, 2006 6:01 PM > To: Fredrik Thulin > Cc: Vavilapalli Srikanth-A19563; SIP WG; Rohan Mahy > Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN > and > SIP traffic > > > I'm not sure about the text in the draft is all clear but ... > > A STUN message can not occur in the middle of a SIP message and > likewise > you can not have a SIP in the middle of the STUN. The streams, the > whole > messages has to be inserted into the stream before starting a new > message regardless of the type of the message. > > On Nov 24, 2006, at 7:22 AM, Fredrik Thulin wrote: > >> Vavilapalli Srikanth-A19563 wrote: >> ... >>> Can anyone please elaborate more on demultiplexing of SIP and STUN >>> message in case of TCP? If the STUN message is in middle of the read >>> buffer, how can we demux these packets? >> >> The STUN header (not sure that is the correct term) is fixed size >> - 20 > >> bytes if I remember correctly. >> >> If you receive one byte that indicates this is STUN then you continue >> reading from the socket until you have received (at least) >> 19 more bytes. From the first 20 bytes you can figure out the total >> length of the STUN request. >> >> /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 25 03:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GntG5-0007S9-CN; Sat, 25 Nov 2006 03:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GntG3-0007Rz-QB for sip@ietf.org; Sat, 25 Nov 2006 03:51:35 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GntFu-0006yH-2j for sip@ietf.org; Sat, 25 Nov 2006 03:51:35 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F3664DD; Sat, 25 Nov 2006 09:51:12 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 09:51:12 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 09:51:11 +0100 Received: from [131.160.126.1] (rvi2-126-gw.lmf.ericsson.se [131.160.126.1]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4F441234E; Sat, 25 Nov 2006 10:51:11 +0200 (EET) Message-ID: <456803FD.6080903@ericsson.com> Date: Sat, 25 Nov 2006 10:51:09 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Sip] Re: Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00) References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> <4A458EB7-4463-412F-B66C-9B645DB7D0F3@estacado.net> <454068A7.5080206@ericsson.com> In-Reply-To: <454068A7.5080206@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2006 08:51:11.0810 (UTC) FILETIME=[DB7B8220:01C7106E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Sip List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ben, per our face-to-face conversation in San Diego, you told me to stress the fact that clients need to have a way to know about the consent status of their operations. I have added the following sentence to the beginning of Section 5.2: Clients need a way to be informed about the status of the operations they requested. The Pending Additions SIP event package [13], which SHOULD be supported by relays, is a way to provide clients with that information. http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt With this addition, all the WGLC comments should be addressed now. I will be submitting shortly. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi Ben, > > yes, I agree we should go for option 1. I have added text explaining > what to do in that case: > > Even though store-and-forward servers perform a useful function and > they are expected to be deployed in most domains, some domains will > not deploy them from day one. However, user agents and relays in > domains without store-and-forward servers can still use this consent > framework. > > When a relay requests permissions from an off-line user agent that > does not have an associated store-and-forward server, the relay will > obtain an error response indicating that its MESSAGE request could > not be delivered. The client that attempted to add the off-line user > to the relay's translation logic will be notified about the error > (e.g., using the Pending Additions event package [13]). This client > MAY attempt to add the same user at a later point, hopefully when the > user is on-line. Clients can discover whether or not a user is on- > line by using a presence service, for instance. > > > > Feel free to edit the text above so that you are happy with it. > > Thanks, > > Gonzalo > > > Ben Campbell wrote: >> I'm separating my response about the consent-framework store and >> forward issue from the other issues, since I think this one needs more >> discussion. Specific's inline >> >> On Oct 25, 2006, at 8:18 AM, Gonzalo Camarillo wrote: >> >> [...] >> >>>> 4.3 >>>>> There are several mechanisms to implement store-and-forward message >>>>> services (e.g., with an instant message to email gateway). Any of >>>>> these mechanisms can be used between a user agent and its >>>>> store-and- forward server as long as they agree on which mechanism >>>>> to use. Therefore, this framework does not make any recommendation >>>>> on the interface between user agents and their store-and-forward >>>>> servers. >>>> It is not clear to me if store-and-forward servers are a required >>>> (i.e. normative) part of the consent architecture, or if they are >>>> just something that might exist. I infer the first, considering the >>>> draft always assumes the existence of them, and there are clear >>>> issues about handling permissions when you can't get a MESSAGE to the >>>> recipient. >>>> If we are going to normatively require them, then I have some >>>> heartburn about the fact that there is no specification of how they >>>> work. I don't expect _this_ doc to specify that, but it should be >>>> somewhere. In particular, if we are going to architecturally require >>>> them, we as a community should be concerned about interoperability >>>> between S&F servers and arbitrary UAs, which this document >>>> _explicitly_ punts on. >>> >>> yes, I agree a clarification is needed. I propose to add the following >>> text at the end of Section 4.3: >>> >>> NEW TEXT: >>> >>> Even though store-and-forward servers perform a useful function and >>> they are expected to be deployed in most domains, some domains will >>> not deploy them from day one. However, user agents and relays in >>> domains without store-and-forward servers can still use this consent >>> framework, although with some limitations. In particular, relays in >>> these domains are not able to request permissions from users that are >>> off-line. >>> >> >> I'm still uncomfortable with this. The proposed text still implies >> that S&F servers are needed for a "complete" consent-framework >> solution, and that the framework essentially fails without them. >> >> 1) Specify consent-framework behavior from the assumption that no such >> thing exists, at least in the common case. That is, talk in some >> detail about what you do when the MESSAGE requests fail, and whether >> you should retry later, how often to retry, etc. We could point out >> that if an S&F type server were present, then an offline target should >> not cause the MESSAGE request to fail, but that would be about all we >> could say about them. >> >> 2) Recognize that the consent-framework has an architectural >> dependency on S&F servers, and have one of the related WGs go down the >> path of specifying one, to be normatively referenced here. >> >> I realize that option 2 is not a tenable solution, as it would block >> progress on the consent-framework for some time. My opinion is that we >> should go with option 1. If at some time in the future we standardize >> an S&F server, we could discuss their use in more detail in a separate >> draft. >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Nov 25 13:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go2Cr-0006gd-Fx; Sat, 25 Nov 2006 13:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go2Cq-0006gY-9f for sip@ietf.org; Sat, 25 Nov 2006 13:24:52 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go2Cl-00082y-OZ for sip@ietf.org; Sat, 25 Nov 2006 13:24:52 -0500 Received: from [192.168.1.100] (adsl-68-94-29-120.dsl.rcsntx.swbell.net [68.94.29.120]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kAPIOUek067499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Nov 2006 12:24:34 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <456803FD.6080903@ericsson.com> References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> <4A458EB7-4463-412F-B66C-9B645DB7D0F3@estacado.net> <454068A7.5080206@ericsson.com> <456803FD.6080903@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Re: Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00) Date: Sat, 25 Nov 2006 12:24:24 -0600 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Sip List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would add a sentence describing the consequences of not having a way to get the status. Otherwise, it looks good to me. Thanks! Ben. On Nov 25, 2006, at 2:51 AM, Gonzalo Camarillo wrote: > Hi Ben, > > per our face-to-face conversation in San Diego, you told me to > stress the fact that clients need to have a way to know about the > consent status of their operations. I have added the following > sentence to the beginning of Section 5.2: > > Clients need a way to be informed about the status of the > operations > they requested. The Pending Additions SIP event package [13], > which > SHOULD be supported by relays, is a way to provide clients with > that > information. > > http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent- > framework-01.txt > > With this addition, all the WGLC comments should be addressed now. > I will be submitting shortly. > > Cheers, > > Gonzalo > > > > Gonzalo Camarillo wrote: >> Hi Ben, >> yes, I agree we should go for option 1. I have added text >> explaining what to do in that case: >> Even though store-and-forward servers perform a useful function >> and >> they are expected to be deployed in most domains, some domains >> will >> not deploy them from day one. However, user agents and relays in >> domains without store-and-forward servers can still use this >> consent >> framework. >> When a relay requests permissions from an off-line user agent that >> does not have an associated store-and-forward server, the relay >> will >> obtain an error response indicating that its MESSAGE request could >> not be delivered. The client that attempted to add the off- >> line user >> to the relay's translation logic will be notified about the error >> (e.g., using the Pending Additions event package [13]). This >> client >> MAY attempt to add the same user at a later point, hopefully >> when the >> user is on-line. Clients can discover whether or not a user is >> on- >> line by using a presence service, for instance. >> Feel free to edit the text above so that you are happy with it. >> Thanks, >> Gonzalo >> Ben Campbell wrote: >>> I'm separating my response about the consent-framework store and >>> forward issue from the other issues, since I think this one needs >>> more discussion. Specific's inline >>> >>> On Oct 25, 2006, at 8:18 AM, Gonzalo Camarillo wrote: >>> >>> [...] >>> >>>>> 4.3 >>>>>> There are several mechanisms to implement store-and-forward >>>>>> message >>>>>> services (e.g., with an instant message to email gateway). >>>>>> Any of >>>>>> these mechanisms can be used between a user agent and its >>>>>> store-and- forward server as long as they agree on which >>>>>> mechanism >>>>>> to use. Therefore, this framework does not make any >>>>>> recommendation >>>>>> on the interface between user agents and their store-and-forward >>>>>> servers. >>>>> It is not clear to me if store-and-forward servers are a required >>>>> (i.e. normative) part of the consent architecture, or if they are >>>>> just something that might exist. I infer the first, considering >>>>> the >>>>> draft always assumes the existence of them, and there are clear >>>>> issues about handling permissions when you can't get a MESSAGE >>>>> to the >>>>> recipient. >>>>> If we are going to normatively require them, then I have some >>>>> heartburn about the fact that there is no specification of how >>>>> they >>>>> work. I don't expect _this_ doc to specify that, but it should be >>>>> somewhere. In particular, if we are going to architecturally >>>>> require >>>>> them, we as a community should be concerned about interoperability >>>>> between S&F servers and arbitrary UAs, which this document >>>>> _explicitly_ punts on. >>>> >>>> yes, I agree a clarification is needed. I propose to add the >>>> following >>>> text at the end of Section 4.3: >>>> >>>> NEW TEXT: >>>> >>>> Even though store-and-forward servers perform a useful >>>> function and >>>> they are expected to be deployed in most domains, some >>>> domains will >>>> not deploy them from day one. However, user agents and >>>> relays in >>>> domains without store-and-forward servers can still use this >>>> consent >>>> framework, although with some limitations. In particular, >>>> relays in >>>> these domains are not able to request permissions from users >>>> that are >>>> off-line. >>>> >>> >>> I'm still uncomfortable with this. The proposed text still >>> implies that S&F servers are needed for a "complete" consent- >>> framework solution, and that the framework essentially fails >>> without them. >>> >>> 1) Specify consent-framework behavior from the assumption that no >>> such thing exists, at least in the common case. That is, talk in >>> some detail about what you do when the MESSAGE requests fail, and >>> whether you should retry later, how often to retry, etc. We could >>> point out that if an S&F type server were present, then an >>> offline target should not cause the MESSAGE request to fail, but >>> that would be about all we could say about them. >>> >>> 2) Recognize that the consent-framework has an architectural >>> dependency on S&F servers, and have one of the related WGs go >>> down the path of specifying one, to be normatively referenced here. >>> >>> I realize that option 2 is not a tenable solution, as it would >>> block progress on the consent-framework for some time. My opinion >>> is that we should go with option 1. If at some time in the future >>> we standardize an S&F server, we could discuss their use in more >>> detail in a separate draft. >>> >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 26 06:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoHnN-0006JR-1S; Sun, 26 Nov 2006 06:03:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoHnL-0006Iq-0R for sip@ietf.org; Sun, 26 Nov 2006 06:03:35 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoHnJ-000491-MQ for sip@ietf.org; Sun, 26 Nov 2006 06:03:34 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1740FA81; Sun, 26 Nov 2006 12:03:33 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 12:03:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 12:03:16 +0100 Received: from [131.160.126.12] (rvi2-126-12.lmf.ericsson.se [131.160.126.12]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 980412356; Sun, 26 Nov 2006 13:03:16 +0200 (EET) Message-ID: <45697473.1080207@ericsson.com> Date: Sun, 26 Nov 2006 13:03:15 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Sip] Re: Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00) References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> <4A458EB7-4463-412F-B66C-9B645DB7D0F3@estacado.net> <454068A7.5080206@ericsson.com> <456803FD.6080903@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2006 11:03:16.0920 (UTC) FILETIME=[79A11380:01C7114A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Sip List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ben, > I would add a sentence describing the consequences of not having a > way to get the status. I have added the following sentence: Clients need a way to be informed about the status of the operations they requested. Otherwise, users may be waiting for an operation to succeed when it has actually already failed. > Otherwise, it looks good to me. Good. I will submit the new revision then. Thanks! Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From vxjmspuomxd@vol.cz Sun Nov 26 10:00:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoLUw-00027z-C6 for sip-archive@lists.ietf.org; Sun, 26 Nov 2006 10:00:50 -0500 Received: from bryndova-fwl.customer.vol.cz ([212.27.218.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoLUu-0001h4-Tl for sip-archive@lists.ietf.org; Sun, 26 Nov 2006 10:00:50 -0500 From: "Earn points" To: sip-archive@lists.ietf.org Subject: Rocket Stock Report Date: Sun, 26 Nov 2006 16:04:56 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C71174.9D8A3EF0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccRdJ2KpLN8f8+aQpC7tjQ7it9dqQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <212F93AB9D93AB3.6F5A4041A6@vol.cz> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ------=_NextPart_000_0000_01C71174.9D8A3EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We Told You!!! BLNM Volume UP 4000% and Price Up 47.06%!
Can You feel The Rocket!??

Company: Bralorne Mining Company
Symbol: BLNM.OB
Price: $0.25 (+47.06% in 1 day)
3 Day Target: $0.75

The News Are Out! Read The Latest on BLNM!

BLNM.OB: Beijing QTC Launches Broadband Phone Service to Beijing Tianzh Airport.
The Bralorne Mining Company (BLNM) announced that its wholly holding subsidiary, Beijing Quan Tong Chang Information Services Limited ("Beijing QTC"), has launched "Intragroup Call," a broadband phone service, to Beijing Tianzhu Airport Industrial Zone which offers more than 300 companies and business partners in the zone broadband phone service, targeting $1.5 million annual profit.

They are working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen.

We knew this was going to take off but we did not expect it till Monday due to the holiday. Well today we saw it climb 47% in price and the volume is up over 4000%. WOW!

We have been told that there will be big news beginning of the week. Monday this will be off the scale. Set your buys for first thing Monday morning. We could see the 3 day projection hit in one day at this rate. Waste no time.

Grab BLNM first thing Monday Morning!!
------=_NextPart_000_0000_01C71174.9D8A3EF0-- From sip-bounces@ietf.org Sun Nov 26 12:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoO6Z-0006Ik-BQ; Sun, 26 Nov 2006 12:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoO6Y-0006DB-21 for sip@ietf.org; Sun, 26 Nov 2006 12:47:50 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoO6W-0005m9-NJ for sip@ietf.org; Sun, 26 Nov 2006 12:47:50 -0500 Received: from [192.168.1.100] (adsl-68-94-29-120.dsl.rcsntx.swbell.net [68.94.29.120]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kAQHlXvG019132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Nov 2006 11:47:38 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <45697473.1080207@ericsson.com> References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> <4A458EB7-4463-412F-B66C-9B645DB7D0F3@estacado.net> <454068A7.5080206@ericsson.com> <456803FD.6080903@ericsson.com> <45697473.1080207@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BCF5DAC-BD65-43D4-BC23-F7F652FF43F1@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Re: Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00) Date: Sun, 26 Nov 2006 11:47:27 -0600 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Sip List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it still needs to be a little more precise on the nature of the failure that can occur if you don't track the status. Something to the effect of : "... In particular, if the target of the consent request was not reachable, the client needs to know to retry the request later." Thanks! Ben. On Nov 26, 2006, at 5:03 AM, Gonzalo Camarillo wrote: > Hi Ben, > >> I would add a sentence describing the consequences of not having a >> way to get the status. > > I have added the following sentence: > > Clients need a way to be informed about the status of the operations > they requested. Otherwise, users may be waiting for an operation to > succeed when it has actually already failed. > >> Otherwise, it looks good to me. > > Good. I will submit the new revision then. > > Thanks! > > Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 26 14:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoPgn-0007x8-Jx; Sun, 26 Nov 2006 14:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoPgl-0007o2-Nn for sip@ietf.org; Sun, 26 Nov 2006 14:29:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoPgc-00061F-FC for sip@ietf.org; Sun, 26 Nov 2006 14:29:19 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FF8F4F0001; Sun, 26 Nov 2006 20:29:03 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 20:29:03 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 20:29:02 +0100 Received: from [131.160.126.88] (rvi2-126-88.lmf.ericsson.se [131.160.126.88]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 616DA2356; Sun, 26 Nov 2006 21:28:58 +0200 (EET) Message-ID: <4569EAF8.6020809@ericsson.com> Date: Sun, 26 Nov 2006 21:28:56 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Sip] Re: Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00) References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> <4A458EB7-4463-412F-B66C-9B645DB7D0F3@estacado.net> <454068A7.5080206@ericsson.com> <456803FD.6080903@ericsson.com> <45697473.1080207@ericsson.com> <5BCF5DAC-BD65-43D4-BC23-F7F652FF43F1@estacado.net> In-Reply-To: <5BCF5DAC-BD65-43D4-BC23-F7F652FF43F1@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2006 19:29:02.0929 (UTC) FILETIME=[21429410:01C71191] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Sip List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ben, OK. The text now reads: Clients need a way to be informed about the status of the operations they requested. Otherwise, users may be waiting for an operation to succeed when it has actually already failed. In particular, if the target of the request for consent was not reachable and did not have an associated store-and-forward server, the client needs to know to retry the request later. Thanks, Gonzalo Ben Campbell wrote: > I think it still needs to be a little more precise on the nature of the > failure that can occur if you don't track the status. Something to the > effect of : > > "... In particular, if the target of the consent request was not > reachable, the client needs to know to retry the request later." > > Thanks! > > Ben. > > On Nov 26, 2006, at 5:03 AM, Gonzalo Camarillo wrote: > >> Hi Ben, >> >>> I would add a sentence describing the consequences of not having a >>> way to get the status. >> >> I have added the following sentence: >> >> Clients need a way to be informed about the status of the operations >> they requested. Otherwise, users may be waiting for an operation to >> succeed when it has actually already failed. >> >>> Otherwise, it looks good to me. >> >> Good. I will submit the new revision then. >> >> Thanks! >> >> Gonzalo > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 26 15:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoQx2-0008VQ-GK; Sun, 26 Nov 2006 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoQws-0008SK-Na; Sun, 26 Nov 2006 15:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoQws-0001cI-Ee; Sun, 26 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id ED4AE26E2B; Sun, 26 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GoQwr-0004DZ-Mb; Sun, 26 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 26 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-06.txt Pages : 41 Date : 2006-11-26 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-outbound-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-26141720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-26141720.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sun Nov 26 20:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoUut-0006lS-I3; Sun, 26 Nov 2006 20:04:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoUus-0006hB-9L for sip@ietf.org; Sun, 26 Nov 2006 20:04:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoUur-0003B2-QI for sip@ietf.org; Sun, 26 Nov 2006 20:04:14 -0500 Received: from [10.10.16.45] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAR08CEw010496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 26 Nov 2006 18:08:12 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP WG From: Dean Willis Date: Sun, 26 Nov 2006 19:04:07 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Subject: [Sip] draft minutes from SIP at IETF 67 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'll try and get these posted shortly on the Proceedings and Softarmor sites. Please review and respond with any corrections. ---------------------------- Draft Minutes for SIP at IETF 67 Edited by Dean Willis Based on notes by David Bryan, Spencer Dawkins, Jason Fischl, Philip Mathews, Chris Boulton, Richard Barnes, and Others. Session 1: Thursday 1300-1500 Grand Ballroom C Topic: Agenda Bash and Status Discussion led by Chairs Slides included in proceedings. Agenda accepted as presented Working group members asked to more thoroughly review the certs draft and consent framework. Topic: Outbound led by Rohan Mahy Read: draft-ietf-sip-outbound-05 Slides included in proceedings. Changes since last version reviewed. Issue: Which response code to use for failures. No objection noted to proposed use of 430 Flow Failed. Issue: Noted that there is no mention of rport in the draft. Author will add text explaining that UA must put rport parameter in Via and send from port it's prepared to receive on, and add informative reference to NAT scenarios document. Issue: Verify outbound support on first or all hops? Discussion seemed to resolve on checking at registrar and first hop. Author will make appropriate changes to the document. Issue: How to resolve possible mismatch in max-flows parameter between visited proxy and home proxy? Discussion of this question was inconclusive, with a general consensus to defer further discussion. Issue: Detecting instance-ID binding rules. This relates to concerns raised by 3GPP. A side meeting with 3GPP was held, and the author thinks he understands the problem and will propose a solution in the next revision of the document. The expected approach is to relax the flow-token language somewhat to allow the specific use case proposed by 3GPP. Topic: Domain Certs led by Vijay Gurbani Slides included in proceedings. Read: draft-gurbani-sip-domain-certs-03 The use of embedded DNS names to indicate the purpose of a certificate was quite controversial and much discussion ensued. The security community holds that extended certificates may be a better solution. Discussion of the document touched on whether the work is required and how it relates to other work. The discussion was inconclusive, and we expect to resolve it via list discussion and possibly a subject-specific conference call. Topic: Connection Reuse led by Vijay Gurbani Slides included in proceedings Read: draft-ietf-sip-connect-reuse-07 Issue: Since the impact of this work has essentially declined to halving the number of TLS between proxies not separated by NATs, should we continue to pursue the work? The opinion of the room was weighted about 5 to 1 against continuing the work. The chairs are tasked to raise this question on the mailing list. Issue: The approach taken by the outbound mid-dialg draft may obviate some of the applicability for this draft. Discussion on this point was inconclusive, and it will be taken as a topic for an upcoming conference call. Issue: The CP behavior in this document contradicts that in draft- ietf-sip-outbound. Topic: SIPS Guidelines led by Francois Audet Slides included in proceeedings Read: draft-audet-sip-sips-guidelines-04 Changes in document since last version reviewed. Issue: 4 point BCP list proposed on-list by Dean Willis. Noted that Item 1 is somewhat out of place, as it simply restates RFC 3261. Suggested that a BCP should perhaps explicitly state this as a "reminder". The room seemed to agree with points 2 and 3. Point 4 remained controversial, with a general consensus emerging that it should be expressed at a "Should" strength along with discussion of the risk model and consequences. Topic: GRUU and Supporting Drafts Led by Jonathan Rosenberg Slides included in proceedings Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 Change since last version reviewed. Issue: GRUU subtype names. The room demonstrated a slight preference for the names used in -11 over known alternatives, but nobody seems particularly enamored with these names and the floor remains open to suggestions. Discussion on ua-loose-route draft deferred to next session. Session 2: Friday 0900-1130 Grand Ballroom C Topic: UA-loose-route, continued from previous session. Consensus noted that we do need some sort of solution for the general problem of delivery of URI parameters across contact-routing operations. Issue: Concerns raised about backward compatibility. Noted that compliant P-CSCF should be OK. Suggested that we have a design team revisit call-flows and analyze for backward compatibility issues. Issue: Does GRUU normatively depend on this work? Resolved: GRUU does not reference this document. However, some participants feel it should, as the benefit of GRUU cannot be fully recognized in the absence of this specification. The chairs asked for a hum, and the consensus of the room is that GRUU and ua-loose-route can proceed independently. Question: Adopt this draft as baseline text for a WG effort, should the ADs approve the milestone? Consensus to adopt noted by chairs. To- do: Chairs to work with AD to set new milestone. Topic: Location Conveyance led by James Polk and Brian Rosen Slides included in proceedings Read: draft-ietf-sip-location-conveyance-05 Changes since last version reviewed. The room discussed trust issues, location-by-value (needs geolocation), and the question of whether it is important to know which entity inserted a location. No changes to the document were noted as being required during this discussion. The chairs polled for acceptability of current direction -- adding to a header. There were no objections noted to this direction. Issue: Where to track the location error created by this draft? Proposed that we have separate registries for SIP and LOST. Further discussion deferred to list and future conference call. To- do: Chairs to establish a conference call for discussion. Topic: Connected Identity led by John Elwell Slides included in proceedings Read: draft-ietf-sip-connected-identity-02 Current status reported as all issues fixed exception for rejection by RFC 4474 verifier. Discussion concluded with a proposal to not make a statement about 428 responses and policy, perhaps add an informational header into a mid-dialog request rather than rejecting outright. Author will work with this approach and revise doc appropriately. Topic: Identity Coexistence led by Jonathan Rosenberg slides included in proceedings Read: draft-rosenberg-sip-identity-coexistence-00 Issue: How to deal with transit networks? This produced an extensive discussion. Proposed that logic in draft is inverted, and that we should perhaps be looking for Identity and falling back to PAID. There seems to be some consensus that this work is valuable, although there is no consensus yet on the documented approach. The author will revise the document for further discussion. Topic: Outbound Discovery and Mid-Dialog Requests led by: Jonathan Rosenberg Slides included in proceedings Read: draft-rosenberg-sip-outbound-discovery-mid-dialog-00 Issue: How to discover in the absence of DNS? There appears to be no consensus on whether this is a requirement. Further discussion deferred to list. Topic: Diagnostic Responses led by Scott Lawrence Slides included in proceedings Read: draft-ietf-sip-hop-limit-diagnostics-03, draft-gurbani-sip- large-udp-response-00 Noted that ongoing NIT work proposes to deprecate provisional responses for non-INVITE transaction. Proposed that SIP Redirection could be used to eliminate problem. Author will bring discussion questions to the mailing list. Topic: UA Profile Delivery led by Dan Petrie Slides included in proceedings Read: draft-ietf-sip-xcap-config-00 draft-petrie-sip-event-param-err-00 Changes since last version reviewed. Noted that OMA has a dependency on XCAP change notifications. To:do; OMA liaison manager to open a dialog on this dependency. Noted that PacketCable 2.0 uses this draft. Topic: Route Constuction Led by Jonathan Rosenberg Slides included in proceedings Read: draft-rosenberg-sip-route-construct-02 Noted that input from IMS vendors is needed to evaluate impact of this proposal. One speaker with some background in IMS opined that this technique should be useful with IMS. Issue: Is Service-Route a reasonable way to provide the outbound proxy set? One speaker didn't think so, but no alternative suggestions were noted. Further discussion deferred to mailing list. Meeting adjourned several minutes past scheduled end of session. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Nov 26 20:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoVWG-0008SJ-EZ; Sun, 26 Nov 2006 20:42:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoVWF-0008SD-8p for sip@ietf.org; Sun, 26 Nov 2006 20:42:51 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoVWB-0004Sz-0K for sip@ietf.org; Sun, 26 Nov 2006 20:42:51 -0500 Received: from [71.254.21.62] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GoVWA-0004hM-Hg for sip@ietf.org; Sun, 26 Nov 2006 20:42:46 -0500 Message-Id: <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 26 Nov 2006 20:42:47 -0500 To: SIP WG From: "Joel M. Halpern" In-Reply-To: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> References: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120e57ded9e3a224f843b99fc955252e1eed59d3f87bb2d8d42350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.21.62 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] Re: SIPS and the PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:04 PM 11/26/2006, Dean Willis wrote: >Issue: 4 point BCP list proposed on-list by Dean Willis. Noted that >Item 1 is somewhat out of place, as it simply restates RFC 3261. >Suggested that a BCP should perhaps explicitly state this as a >"reminder". The room seemed to agree with points 2 and 3. Point 4 >remained controversial, with a general consensus emerging that it >should be expressed at a "Should" strength along with discussion of >the risk model and consequences. I think the discussion of point 4 at the meeting may have missed the point. Point 4 says basically that PSTN gateway termination can not use SIPS (to put it in the most pejorative fashion and then defend it.) Point 1 is that everyone should use TLS. Since 3261 already says this, saying it again is not a change. It doesn't hurt to restate it. The argument has been that SIPS (inside the IP cloud) means "MUST use TLS." It has been clearly stated and agreed that it is not acceptable to use "or equivalent security." Well, if "equivalent security is NOT okay in the IP domain, why is it okay for the PSTN? Do they get a free pass? It seems to me that if we are going to tell secure providers of VoIP that they must reject SIPS requests (on the grounds that it isn't TLS, and if that was not required by the caller the caller should have just used SIP) then we owe it to ourselves and the users to make the same assertion about the PSTN. Note, I am not claiming that the PSTN is less secure. I am merely saying that if "equivalent security" is not acceptable, then it is not acceptable. (I will refrain from rehashing the arguments on the marginal utility of SIPS anyway.) Yours, Joel M. Halpern _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 00:03:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYcR-0001ox-VL; Mon, 27 Nov 2006 00:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoYcQ-0001op-Gv for sip@ietf.org; Mon, 27 Nov 2006 00:01:26 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GoYcO-0002Qa-90 for sip@ietf.org; Mon, 27 Nov 2006 00:01:26 -0500 X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1164603676!14745155!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.100] Received: (qmail 29046 invoked from network); 27 Nov 2006 05:01:16 -0000 Received: from motgate.mot.com (HELO motgate.mot.com) (129.188.136.100) by server-15.tower-119.messagelabs.com with SMTP; 27 Nov 2006 05:01:16 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motorola) with ESMTP id kAR51Fps027246 for ; Sun, 26 Nov 2006 22:01:15 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kAR51DFe019216 for ; Sun, 26 Nov 2006 23:01:14 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Date: Mon, 27 Nov 2006 13:01:12 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA10154D372@ZMY16EXM67.ds.mot.com> In-Reply-To: <4566EFA7.3000106@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Thread-Index: AccPykLjwrPx8YFETqSqZ/uXbj5iPgCFNDHg From: "Vavilapalli Srikanth-A19563" To: "Fredrik Thulin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Cullen Jennings , SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org True, without parsing entire SIP message we would not know about the existence of STUN packets.=20 The reason behind posting this question is coming more from implementation point of view. Suppose if some implementations receive the messages from TCP sockets in one thread and process them in other thread contexts and if it is the responsibility of receiving thread to demux the packets and give it to individual threads, then it would be a problem (If the receiving thread gives the entire second read buffer to SIP processing thread, unless there is a way to get back the remaining buffer from SIP thread, the receive thread can not handover the STUN packet to STUN processing thread) When the draft mentioned the demuxing based on the first octet in case of TCP was a strightforward solution, I thought there might be already a simple solution for the scenario described above. One solution I thought of was looking for STUN magic cokkie (combined with Message Type or finger print) in each an every received packet from the socket and distribute the packets to individual processing threads. But then the magic cokkie part could have been split across multiple TCP reads, so this solution won't work. Regards Srikanth=20 -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se]=20 Sent: Friday, November 24, 2006 6:42 PM To: Vavilapalli Srikanth-A19563 Cc: Cullen Jennings; SIP WG; Rohan Mahy Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic Vavilapalli Srikanth-A19563 wrote: > Sorry for the confusion.=20 >=20 > What I mean "in middle of the read buffer" is, For ex: In the first=20 > read I received a partial SIP message and in the next TCP read if I=20 > receive the remaining of the SIP message and followed by STUN message=20 > (in single read, and I believe this is possible in TCP communication), > then demuxing will be difficult unless we parse the entire SIP message. No, demuxing will be _impossible_ unless you parse the entire SIP message first. I can't think of a single reason why one would not want to parse the complete SIP message first, can you please explain? /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 04:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GocLt-0001NF-JN; Mon, 27 Nov 2006 04:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GocLs-0001NA-Ek for sip@ietf.org; Mon, 27 Nov 2006 04:00:36 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GocLp-0003uT-05 for sip@ietf.org; Mon, 27 Nov 2006 04:00:36 -0500 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kAR90RYJ007257 for ; Mon, 27 Nov 2006 03:00:29 -0600 (CST) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Nov 2006 16:59:23 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Nov 2006 16:59:22 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] automatically switches to TCP Date: Mon, 27 Nov 2006 16:56:33 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] automatically switches to TCP thread-index: AccO8/K6tmCI6NY1QH61UsLroxuH0QAATt/wADEnkbAAB//hMACJt1FQ From: "Xia, Zhi Feng \(Bruce\)" To: , "IETF SIP List" X-OriginalArrivalTime: 27 Nov 2006 08:59:22.0077 (UTC) FILETIME=[5487D0D0:01C71202] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0110974863==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0110974863== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71201.F0400030" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71201.F0400030 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Manju, 1. Is this documented somewhere?=20 2. We had a stack which sends messages over UDP as mandated by UA, if = UDP failure or transaction timeout(e.g. after 7 retrys of INVITE) it = switches to TCP instead of going into terminated state -- this sounds = violate your "MUST"? =20 Thanks, Bruce -----Original Message----- From: Manjunath Warad [mailto:manjunathwarad@huawei.com] Sent: 2006?11?24? 11:07 PM To: 'Xia, Zhi Feng (Bruce)'; 'IETF SIP List' Subject: RE: [Sip] automatically switches to TCP Hi Bruce, I think this is other way round, if sending on TCP fails then it is = recommended to try on UDP to keep the backward compatibility with RFC = 2543.=20 After timeout transaction MUST enter into terminated state and will not = retry by changing the protocol. =20 Regards, Manju =20 *************************************************************************= ************** This e-mail and attachments contain confidential information = from HUAWEI, which is intended only for the person or entity whose = address is listed above. Any use of the information contained herein in = any way (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it! =20 _____ =20 From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com]=20 Sent: Friday, November 24, 2006 4:47 PM To: IETF SIP List Subject: [Sip] automatically switches to TCP Hi, There're many implementations when transportation on UDP fails or = transation timeout without response it will automatically try TCP = connection. Is this mandated in any RFCs? I think RFC3261 says if = transaction timeouts it should go to terminated state. =20 Is this implementation a violation to RFC3261? =20 Thanks, Bruce ------_=_NextPart_001_01C71201.F0400030 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi=20 Manju,
1. = Is this=20 documented somewhere?
2. = We had a stack=20 which sends messages over UDP as mandated by UA, if UDP failure or = transaction=20 timeout(e.g. after 7 retrys of INVITE) it switches to TCP instead of = going into=20 terminated state -- this sounds violate your "MUST"?
 
Thanks,
Bruce
-----Original Message-----
From: Manjunath Warad=20 [mailto:manjunathwarad@huawei.com]
Sent: 2006?11?24? 11:07=20 PM
To: 'Xia, Zhi Feng (Bruce)'; 'IETF SIP = List'
Subject:=20 RE: [Sip] automatically switches to TCP

Hi Bruce,
   =20 I think this is other = way round, if=20 sending on TCP fails then it is recommended to try on UDP to keep = the=20 backward compatibility with RFC 2543.
After timeout transaction MUST enter = into terminated=20 state and will not retry by changing the protocol.
 
Regards,
Manju
 

******************************************************************= *********************

           =20 This e-mail and attachments contain confidential information = from=20 HUAWEI, which is intended only for the person or entity whose address = is=20 listed above. Any use of the information contained herein in any way=20 (including, but not limited to, total or partial disclosure, = reproduction, or=20 dissemination) by persons other than the intended recipient's) is = prohibited.=20 If you receive this e-mail in error, please notify the sender by phone = or=20 email immediately and delete it!

 

From: Xia, Zhi Feng (Bruce)=20 [mailto:brucex@lucent.com]
Sent: Friday, November 24, = 2006 4:47=20 PM
To: IETF SIP List
Subject: [Sip] = automatically=20 switches to TCP

Hi,
There're many implementations when transportation on UDP = fails or=20 transation timeout without response it will automatically try TCP=20 connection. Is this mandated in any RFCs? I think RFC3261 says if=20 transaction timeouts it should go to terminated = state.
 
Is=20 this implementation a violation to RFC3261?
 
Thanks,
Bruce
------_=_NextPart_001_01C71201.F0400030-- --===============0110974863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0110974863==-- From sip-bounces@ietf.org Mon Nov 27 05:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GodQR-0004QR-B0; Mon, 27 Nov 2006 05:09:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GodQP-0004Oq-9x for sip@ietf.org; Mon, 27 Nov 2006 05:09:21 -0500 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GodQN-0001NT-R0 for sip@ietf.org; Mon, 27 Nov 2006 05:09:21 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id D963A21002B; Mon, 27 Nov 2006 11:09:00 +0100 (CET) Message-ID: <456AB942.3080702@pernau.at> Date: Mon, 27 Nov 2006 11:09:06 +0100 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] outbound-06 submitted References: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> In-Reply-To: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan! I have a question regarding sending with TLS in section 4.3: > 4.3 Sending Requests > > When a UA is about to send a request, it first performs normal > processing to select the next hop URI. The UA can use a variety of > techniques to compute the route set and accordingly the next hop URI. > Discussion of these techniques is outside the scope of this document > but could include mechanisms specified in RFC 3608 [RFC3608] (Service > Route) and [I-D.rosenberg-sip-route-construct]. > > The UA performs normal DNS resolution on the next hop URI (as > described in RFC 3263 [RFC3263]) to find a protocol, IP address, and > port. For non-TLS protocols, if the UA has an existing flow to this > IP address, and port with the correct protocol, then the UA MUST use > the existing connection. For TLS protocols, there MUST also be a > match between the host production in the next hop and one of the URIs > contained in the subjectAltName in the peer certificate. If the UA > cannot use one of the existing flows, then it SHOULD form a new flow > by sending a datagram or opening a new connection to the next hop, as > appropriate for the transport protocol. The UA is only allowed to reuse a TLS connection, if the host production of the next hop is also present in the subjectAltName of the peer's certificate. Otherwise it should open a new TLS connection to the next hop. But as this new connection is sent to the same remote socket, it is very likely that the peer's certificate in the new TLS connection is the same as in the existing connection, unless the client and server are capable of the "Server Name Indication" TLS extension. Thus, what about suggesting this TLS extension? regards klaus Rohan Mahy wrote: > Hi, > > I submitted -06 of outbound so folks can at least take a look to see > that the many small changes we have agreed to have been incorporated. > I also included the proposed text for FASTEST, since the draft would > need significant surgery anyway if we go with CLEANEST. > > Until it appears in the archive you can find it here: > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-06.html > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-06.txt > > > 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 -- Klaus Darilion nic.at _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 06:17:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoeSZ-0000NJ-6r; Mon, 27 Nov 2006 06:15:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoeSX-0000N5-QC for sip@ietf.org; Mon, 27 Nov 2006 06:15:37 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoeSR-0007H4-Ei for sip@ietf.org; Mon, 27 Nov 2006 06:15:37 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J9D00MCVYZKQJ@siemenscomms.co.uk> for sip@ietf.org; Mon, 27 Nov 2006 11:09:20 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Nov 2006 11:09:11 +0000 Content-return: allowed Date: Mon, 27 Nov 2006 11:09:02 +0000 From: "Elwell, John" Subject: RE: [Sip] draft minutes from SIP at IETF 67 To: Dean Willis , SIP WG Message-id: <50B1CBA96870A34799A506B2313F26670A6DD848@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Topic: Connected Identity > led by John Elwell > Slides included in proceedings > Read: draft-ietf-sip-connected-identity-02 > > Current status reported as all issues fixed exception for rejection > by RFC 4474 verifier. > > Discussion concluded with a proposal to not make a statement about > 428 responses and policy, perhaps add an informational header into a > mid-dialog request rather than rejecting outright. [JRE] I recall there was some mention of an informational header, but it was not clear to me exactly what the intention was and whether it was intended for use instead of an outright rejection. I am about to issue a further revision that takes account of the consensus at the meeting but without introducing any new header field. If anybody has a concrete proposal for such a header field, please make it known as soon as possible. John > > Author will work with this approach and revise doc appropriately. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 13:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolBx-0001fP-2f; Mon, 27 Nov 2006 13:26:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolBv-0001eD-H1 for sip@ietf.org; Mon, 27 Nov 2006 13:26:55 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GolBu-0005t3-AS for sip@ietf.org; Mon, 27 Nov 2006 13:26:55 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2006112718265301200ornqpe>; Mon, 27 Nov 2006 18:26:53 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kARIQr69001736 for ; Mon, 27 Nov 2006 13:26:53 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kARIQrQP001732; Mon, 27 Nov 2006 13:26:53 -0500 Date: Mon, 27 Nov 2006 13:26:53 -0500 Message-Id: <200611271826.kARIQrQP001732@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <608D7BFF0D57794785CBC2C440BC4FA10154D372@ZMY16EXM67.ds.mot.com> (srikanthv@motorola.com) Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP traffic References: <608D7BFF0D57794785CBC2C440BC4FA10154D372@ZMY16EXM67.ds.mot.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Vavilapalli Srikanth-A19563" The reason behind posting this question is coming more from implementation point of view. Suppose if some implementations receive the messages from TCP sockets in one thread and process them in other thread contexts and if it is the responsibility of receiving thread to demux the packets and give it to individual threads, then it would be a problem (If the receiving thread gives the entire second read buffer to SIP processing thread, unless there is a way to get back the remaining buffer from SIP thread, the receive thread can not handover the STUN packet to STUN processing thread) The receiving thread must assemble the read buffers into a byte stream, then parse the byte stream to find the message boundaries, and copy the messages it finds into different buffers, and pass those buffers to the processing thread. It is a *very* general rule that when reading input from TCP, the "read buffer" boundaries have no correspondance to *any* feature of the data in the input stream. The code that reads the TCP socket must assemble the read buffers into a continuous input stream and parse them in the way that is appropriate for the data. You would be amused at the number of programs that die if you feed them input on a TCP connection with one byte per TCP packet, because the TCP stack gives one byte read buffers to the reader process, and the reader process can't cope with that. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 15:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonR6-0004KW-Rr; Mon, 27 Nov 2006 15:50:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQu-0003yJ-J7; Mon, 27 Nov 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GonQu-0004gC-99; Mon, 27 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 01F1C175DB; Mon, 27 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FR-J7; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-consent-framework-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-sip-consent-framework-01.txt Pages : 27 Date : 2006-11-27 The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification, and DoS (Denial of Service) attacks. This document identifies a framework for consent- based communications in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-consent-framework-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-consent-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-27102923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-consent-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-consent-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27102923.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Nov 27 16:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gonn9-0001XO-Me; Mon, 27 Nov 2006 16:13:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gonn8-0001Ww-5s for sip@ietf.org; Mon, 27 Nov 2006 16:13:30 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gonn6-0006KK-TW for sip@ietf.org; Mon, 27 Nov 2006 16:13:30 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kARLDPV29795; Mon, 27 Nov 2006 16:13:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Date: Mon, 27 Nov 2006 15:13:21 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E280542@zrc2hxm0.corp.nortel.com> In-Reply-To: <953beacc0611211715o72738782ua974a41ecd07132@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] strawman text for FASTEST proposal in outbound thread-index: AccN06k4w1SCFoZuRPyIJWWTflcfIgElReRw From: "Francois Audet" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I understand Rohan, but the current text is confusing. I prefer the "switchover" explanation you gave below. Or something along the lines of what Spencer proposed in his posting.=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: Tuesday, November 21, 2006 17:15 > To: Audet, Francois (SC100:3055) > Cc: SIP WG; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] strawman text for FASTEST proposal in outbound >=20 > Hi Francois, >=20 > On 11/21/06, Francois Audet wrote: > > > > > To make the discussion about the outbound transport issues more=20 > > > concrete, here is some strawman text for the "FASTEST" direction. > > > > > > thanks, > > > -rohan > > > > > > PROPOSED TEXT: > > > Use of outbound with UDP flows prevents messages larger than 1300=20 > > > bytes from being delivered using TCP as described in > > ^^^ > > Shouldn't this say "UDP"? >=20 > No. Outbound using UDP flows prevents the switchover to a=20 > congestion-controlled transport, such as TCP as described in=20 > this quote from RFC 3261: >=20 > If a request is within 200 bytes of the path MTU, or if=20 > it is larger than 1300 bytes and the path MTU is unknown, the=20 > request MUST be sent using an RFC 2914 [36] congestion=20 > controlled transport protocol, such as TCP. If this causes a=20 > change in the transport protocol from the one indicated in=20 > the top Via, the value in the top Via MUST be changed. This=20 > prevents fragmentation of messages over UDP and provides=20 > congestion control for larger messages. >=20 > thanks, > -rohan >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 16:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goo8r-0003at-Ur; Mon, 27 Nov 2006 16:35:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goo8q-0003aR-JY for sip@ietf.org; Mon, 27 Nov 2006 16:35:56 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goo8p-0002lW-B4 for sip@ietf.org; Mon, 27 Nov 2006 16:35:56 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kARLZfc13859; Mon, 27 Nov 2006 16:35:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft minutes from SIP at IETF 67 Date: Mon, 27 Nov 2006 15:35:25 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2805C4@zrc2hxm0.corp.nortel.com> In-Reply-To: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft minutes from SIP at IETF 67 thread-index: AccRwOj3TCpIxMKTTGGjUzz3j9Lq/QAqTJ+w From: "Francois Audet" To: "Dean Willis" , "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Topic: SIPS Guidelines > led by Francois Audet > Slides included in proceeedings > Read: draft-audet-sip-sips-guidelines-04 >=20 > Changes in document since last version reviewed. >=20 > Issue: 4 point BCP list proposed on-list by Dean Willis. Noted that =20 > Item 1 is somewhat out of place, as it simply restates RFC 3261. =20 > Suggested that a BCP should perhaps explicitly state this as a =20 > "reminder". The room seemed to agree with points 2 and 3. Point 4 =20 > remained controversial, with a general consensus emerging that it =20 > should be expressed at a "Should" strength along with discussion of =20 > the risk model and consequences. I think your description of Point 4 is missing a few things. I think the group agreed that "SIPS termination SHOULD be used for all derived connections" when possible. The key point was that there was a concensus that using SIPS to a PSTN gateway was legal. The rationale what that the scope of this document stops at SIP boundaries. Specifically, in the SIP "cloud", implementations SHOULD use SIPS for derived=20 connections. An example of where this is is important is a B2BUA. And then we would put some wording that what happens outside the SIP network is out of scope of this document. Some other networks (e.g., H.323) may have some equivalent security mechanism. Again, the key point was allowing for SIPS to PSTN gateways. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 16:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GooFp-0008E5-NK; Mon, 27 Nov 2006 16:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GooFp-0008Dz-2K for sip@ietf.org; Mon, 27 Nov 2006 16:43:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GooFn-0003kr-H3 for sip@ietf.org; Mon, 27 Nov 2006 16:43:09 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2006 13:43:05 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kARLh5P2032117; Mon, 27 Nov 2006 13:43:05 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kARLgZdc016155; Mon, 27 Nov 2006 13:43:01 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 16:42:53 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 16:42:53 -0500 Message-ID: <456B5BDC.6030805@cisco.com> Date: Mon, 27 Nov 2006 16:42:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Sip] Re: SIPS and the PSTN References: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 21:42:53.0325 (UTC) FILETIME=[FE2983D0:01C7126C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1860; t=1164663785; x=1165527785; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20; bh=Cop3sUaQvr2jiEMQlpXEdI6g4U0IlbAYCbCByLxNoUg=; b=kfEpNHQGhXVz1ql384OWPLLhhpXL0JCt+WeqDRdXNTgisP4dgBiVyhNoZCK059HH2mAQ3J8B /JxEcBsxVCRAkyydN39mlWrVeNLzyEIg5AqhzrekcwpdW/giCBRWvAaf; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments inline ... Joel M. Halpern wrote: > At 08:04 PM 11/26/2006, Dean Willis wrote: >> Issue: 4 point BCP list proposed on-list by Dean Willis. ... >> Point 4 >> remained controversial, with a general consensus emerging that it >> should be expressed at a "Should" strength along with discussion of >> the risk model and consequences. I don't recall any such consensus. > I think the discussion of point 4 at the meeting may have missed the point. > Point 4 says basically that PSTN gateway termination can not use SIPS > (to put it in the most pejorative fashion and then defend it.) ... > The argument has been that SIPS (inside the IP cloud) means "MUST use > TLS." It has been clearly stated and agreed that it is not acceptable > to use "or equivalent security." > Well, if "equivalent security is NOT okay in the IP domain, why is it > okay for the PSTN? Do they get a free pass? It seems to me that if we > are going to tell secure providers of VoIP that they must reject SIPS > requests (on the grounds that it isn't TLS, and if that was not required > by the caller the caller should have just used SIP) then we owe it to > ourselves and the users to make the same assertion about the PSTN. > Note, I am not claiming that the PSTN is less secure. I am merely > saying that if "equivalent security" is not acceptable, then it is not > acceptable. The above seems to be a rehash of the prior on-list arguments made in support of this conclusion. IMO if the request has reached a UAS that is properly authenticated as the intended recipient of the request, then the contract implied by SIPS has been fulfilled, and what happens after that is out of scope. Whether that UAS happens to be a gateway is irrelevant as long as it has the proper credentials for the target address. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Nov 27 22:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gotm6-0002Fd-EB; Mon, 27 Nov 2006 22:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gotm5-0002FY-39 for sip@ietf.org; Mon, 27 Nov 2006 22:36:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gotm3-0008KS-Nw for sip@ietf.org; Mon, 27 Nov 2006 22:36:49 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2006 19:36:47 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAS3al4e025884; Mon, 27 Nov 2006 19:36:47 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAS3aiio029862; Mon, 27 Nov 2006 19:36:44 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 19:36:44 -0800 Received: from [192.168.1.3] ([10.21.122.59]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 19:36:44 -0800 In-Reply-To: <456B5BDC.6030805@cisco.com> References: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> <456B5BDC.6030805@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B9D0728-E7F0-4F0A-9781-D369A957EC38@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: SIPS and the PSTN Date: Mon, 27 Nov 2006 19:36:56 -0800 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Nov 2006 03:36:44.0300 (UTC) FILETIME=[6CCF34C0:01C7129E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2370; t=1164685007; x=1165549007; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20; bh=oo1y+MtjtEsXuk18veOBS/t3sMoIGV6zwJfgYvoSz/8=; b=VbTzAF0Q9n/cJ9062R7+X70Io285GqVfpjsuoD+u3V78ytoAsB5ntIpM/gR9dxFEXWrd1wir sS15NBwXBfL+7rC9++ugwmEteJK/f0rnbTR+iByZlp81ntMpXPrqQU2r; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "Joel M. Halpern" , SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 27, 2006, at 1:42 PM, Paul Kyzivat wrote: > Comments inline ... > > Joel M. Halpern wrote: >> At 08:04 PM 11/26/2006, Dean Willis wrote: >>> Issue: 4 point BCP list proposed on-list by Dean Willis. > ... >>> Point 4 >>> remained controversial, with a general consensus emerging that it >>> should be expressed at a "Should" strength along with discussion of >>> the risk model and consequences. > > I don't recall any such consensus. > >> I think the discussion of point 4 at the meeting may have missed >> the point. >> Point 4 says basically that PSTN gateway termination can not use >> SIPS (to put it in the most pejorative fashion and then defend it.) > ... >> The argument has been that SIPS (inside the IP cloud) means "MUST >> use TLS." It has been clearly stated and agreed that it is not >> acceptable to use "or equivalent security." >> Well, if "equivalent security is NOT okay in the IP domain, why is >> it okay for the PSTN? Do they get a free pass? It seems to me >> that if we are going to tell secure providers of VoIP that they >> must reject SIPS requests (on the grounds that it isn't TLS, and >> if that was not required by the caller the caller should have just >> used SIP) then we owe it to ourselves and the users to make the >> same assertion about the PSTN. >> Note, I am not claiming that the PSTN is less secure. I am merely >> saying that if "equivalent security" is not acceptable, then it is >> not acceptable. > > The above seems to be a rehash of the prior on-list arguments made > in support of this conclusion. > > IMO if the request has reached a UAS that is properly authenticated > as the intended recipient of the request, then the contract implied > by SIPS has been fulfilled, and what happens after that is out of > scope. Whether that UAS happens to be a gateway is irrelevant as > long as it has the proper credentials for the target address. > > Paul I don't remember what the consensus was but I'm seem to recall making a similar argument to Paul. Perhaps someone could listen to the audio recordings of this and try and straight it out. I would be very surprised if we had consensus that if one side of a IP to IP gateway (such as protocol translator) was doing sips that the other side also had to do sips. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 00:29:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GovUx-0001pK-KD; Tue, 28 Nov 2006 00:27:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GovUw-0001pE-I2 for sip@ietf.org; Tue, 28 Nov 2006 00:27:14 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GovUs-0003Jl-4M for sip@ietf.org; Tue, 28 Nov 2006 00:27:14 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9F005KRDHZG3@szxga02-in.huawei.com> for sip@ietf.org; Tue, 28 Nov 2006 13:20:24 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9F00FPHDHYU1@szxga02-in.huawei.com> for sip@ietf.org; Tue, 28 Nov 2006 13:20:23 +0800 (CST) Received: from manjunath ([10.18.8.69]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9F00D77DHUWS@szxml03-in.huawei.com> for sip@ietf.org; Tue, 28 Nov 2006 13:20:22 +0800 (CST) Date: Tue, 28 Nov 2006 10:50:17 +0530 From: Manjunath Warad Subject: RE: [Sip] automatically switches to TCP In-reply-to: To: "'Xia, Zhi Feng (Bruce)'" , 'IETF SIP List' Message-id: <003501c712ac$e48ab940$4508120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook 11 Thread-index: AccO8/K6tmCI6NY1QH61UsLroxuH0QAATt/wADEnkbAAB//hMACJt1FQACrYpDA= X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manjunathwarad@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078158384==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2078158384== Content-type: multipart/alternative; boundary="Boundary_(ID_ziRCjvYpCeo/v4tGc2rBIw)" This is a multi-part message in MIME format. --Boundary_(ID_ziRCjvYpCeo/v4tGc2rBIw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Bruce, See inline... Regards, Manju **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com] Sent: Monday, November 27, 2006 2:27 PM To: manjunathwarad@huawei.com; IETF SIP List Subject: RE: [Sip] automatically switches to TCP Hi Manju, 1. Is this documented somewhere? About switching of protocol, it is documented in RFC 3261 in sec 18.1.1. "If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification. " About transaction moving to terminated state, check in the transaction part of RFC 3261. 2. We had a stack which sends messages over UDP as mandated by UA, if UDP failure or transaction timeout(e.g. after 7 retrys of INVITE) it switches to TCP instead of going into terminated state -- this sounds violate your "MUST"? I am not sure why this behaviour is implemented; however, I think this is violation of standard. Thanks, Bruce -----Original Message----- From: Manjunath Warad [mailto:manjunathwarad@huawei.com] Sent: 2006?11?24? 11:07 PM To: 'Xia, Zhi Feng (Bruce)'; 'IETF SIP List' Subject: RE: [Sip] automatically switches to TCP Hi Bruce, I think this is other way round, if sending on TCP fails then it is recommended to try on UDP to keep the backward compatibility with RFC 2543. After timeout transaction MUST enter into terminated state and will not retry by changing the protocol. Regards, Manju **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com] Sent: Friday, November 24, 2006 4:47 PM To: IETF SIP List Subject: [Sip] automatically switches to TCP Hi, There're many implementations when transportation on UDP fails or transation timeout without response it will automatically try TCP connection. Is this mandated in any RFCs? I think RFC3261 says if transaction timeouts it should go to terminated state. Is this implementation a violation to RFC3261? Thanks, Bruce --Boundary_(ID_ziRCjvYpCeo/v4tGc2rBIw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi Bruce,
    See inline...
 
Regards,
Manju

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com]
Sent: Monday, November 27, 2006 2:27 PM
To: manjunathwarad@huawei.com; IETF SIP List
Subject: RE: [Sip] automatically switches to TCP

Hi Manju,
1. Is this documented somewhere?  
    About switching of protocol, it is documented in RFC 3261 in sec 18.1.1.
 
"If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP. This is only to provide
backwards compatibility with RFC 2543 compliant implementations that
do not support TCP. It is anticipated that this behavior will be
deprecated in a future revision of this specification. " 
 
    About transaction moving to terminated state, check in the transaction part of RFC 3261.
 
2. We had a stack which sends messages over UDP as mandated by UA, if UDP failure or transaction timeout(e.g. after 7 retrys of INVITE) it switches to TCP instead of going into terminated state -- this sounds violate your "MUST"?
    I am not sure why this behaviour is implemented; however,  I think this is violation of standard.
 
Thanks,
Bruce
-----Original Message-----
From: Manjunath Warad [mailto:manjunathwarad@huawei.com]
Sent: 2006?11?24? 11:07 PM
To: 'Xia, Zhi Feng (Bruce)'; 'IETF SIP List'
Subject: RE: [Sip] automatically switches to TCP

Hi Bruce,
    I think this is other way round, if sending on TCP fails then it is recommended to try on UDP to keep the backward compatibility with RFC 2543.
After timeout transaction MUST enter into terminated state and will not retry by changing the protocol.
 
Regards,
Manju
 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com]
Sent: Friday, November 24, 2006 4:47 PM
To: IETF SIP List
Subject: [Sip] automatically switches to TCP

Hi,
There're many implementations when transportation on UDP fails or transation timeout without response it will automatically try TCP connection. Is this mandated in any RFCs? I think RFC3261 says if transaction timeouts it should go to terminated state.
 
Is this implementation a violation to RFC3261?
 
Thanks,
Bruce
--Boundary_(ID_ziRCjvYpCeo/v4tGc2rBIw)-- --===============2078158384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2078158384==-- From sip-bounces@ietf.org Tue Nov 28 02:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gox9p-0005lv-Jz; Tue, 28 Nov 2006 02:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gox9n-0005lp-Os for sip@ietf.org; Tue, 28 Nov 2006 02:13:31 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gox9m-0000sB-Fz for sip@ietf.org; Tue, 28 Nov 2006 02:13:31 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 766E83BEF4; Tue, 28 Nov 2006 08:13:11 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20447-02-36; Tue, 28 Nov 2006 08:13:11 +0100 (CET) Received: from [193.11.30.14] (dhcp-wavelan-vo-14.publik.su.se [193.11.30.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 151E53BE3E; Tue, 28 Nov 2006 08:13:04 +0100 (CET) Message-ID: <456BE164.3080908@it.su.se> Date: Tue, 28 Nov 2006 08:12:36 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rohan Mahy , SIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.65 tagged_above=-99 required=7 tests=[AWL=0.015, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Sip] outbound: question on flow token algorithms X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Outbound (-06) "5.2 Generating Flow Tokens" says "A proxy can use any algorithm it wants as long as the flow token is unique to a flow, the flow can be recovered from the token, and the token can not be modified by attackers." and then goes on explaining two stateless algorithms that both, if I understand them correctly, would generate a static flow token for a given flow (static for as long as the proxy is running). Can you please explain what attack scenarios this is meant to avoid? Algorithm #1 MUST NOT be used if SIPS isn't being used between the edge proxy and the registrar, but I don't really see which attacks would be possible if algorithm #1 was used without SIPS, that would not also be possible with algorithm #2 without SIPS. Perhaps the problem is that I don't interpret "can not be modified by attackers" correctly - please explain what you mean by that too =). /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 06:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0xi-0002vj-D0; Tue, 28 Nov 2006 06:17:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0xf-0002sh-Q1 for sip@ietf.org; Tue, 28 Nov 2006 06:17:16 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp0xY-0005fZ-Bu for sip@ietf.org; Tue, 28 Nov 2006 06:17:15 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kASBH79w029545 for ; Tue, 28 Nov 2006 05:17:07 -0600 (CST) Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 05:17:07 -0600 Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 05:17:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 12:17:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C712DE.BC57C968" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 28 Nov 2006 12:17:03 +0100 Message-ID: <5D1A7985295922448D5550C94DE291808849C5@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-sip-04.txt Thread-Index: AccSZdTyPnOU7bObQQqpjp6Tpr9uVwAdVv6g From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 28 Nov 2006 11:17:05.0713 (UTC) FILETIME=[BC745A10:01C712DE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Sip] FW: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-sip-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C712DE.BC57C968 Content-Type: text/plain; name="warning1.txt" Content-Disposition: inline; filename="warning1.txt" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) WARNING: This e-mail has been altered by some SMTP protection software. Following this paragraph are indications of the actual changes made. For more information, contact . An attachment named draft-ietf-rohc-sigcomp-sip-04.URL was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. ------_=_NextPart_001_01C712DE.BC57C968 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (As WG chair) The document referred to defines=20 - 'sigcomp-id' Via header field parameter - 'sigcomp-id' SIP URI parameter This was previously brought to the attention of the SIP list, but just to be formal, we would like to give a two week WGLC session in the SIP WG in parallel to the one that will occur in the ROHC working group. Please therefore review and comment on the current version of this document by Tuesday 12th December 2006, in particular to the parts that define these parameters. Please send your comments to the IETF ROHC list rather than to the IETF SIP list. Regards Keith -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: 27 November 2006 20:50 To: i-d-announce@ietf.org Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-sip-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) Author(s) : Z. Liu, et al. Filename : draft-ietf-rohc-sigcomp-sip-04.txt Pages : 20 Date : 2006-11-27 =09 This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-sip-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-sip-04.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C712DE.BC57C968 Content-Type: application/octet-stream; name="ATT58580.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT58580.TXT Content-Disposition: attachment; filename="ATT58580.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10 eXBlPSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9y ZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8 MjAwNi0xMS0yNzEwMjUzMS5JLURAaWV0Zi5vcmc+DQoNCkVOQ09ESU5HIG1p bWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvaGMtc2ln Y29tcC1zaXAtMDQudHh0DQo= ------_=_NextPart_001_01C712DE.BC57C968 Content-Type: text/plain; name="ATT58581.txt" Content-Transfer-Encoding: base64 Content-Description: ATT58581.txt Content-Disposition: attachment; filename="ATT58581.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClJvaGMgbWFpbGluZyBsaXN0DQpSb2hjQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2hjDQo= ------_=_NextPart_001_01C712DE.BC57C968 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C712DE.BC57C968-- From sip-bounces@ietf.org Tue Nov 28 10:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5FJ-00028t-7H; Tue, 28 Nov 2006 10:51:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5FH-00028f-OZ for sip@ietf.org; Tue, 28 Nov 2006 10:51:43 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5FE-0007Gs-EU for sip@ietf.org; Tue, 28 Nov 2006 10:51:43 -0500 Received: from [10.78.230.223] (mobile-166-137-232-022.mycingular.net [166.137.232.22]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kASEtR9S020949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Nov 2006 08:55:35 -0600 In-Reply-To: <456B5BDC.6030805@cisco.com> References: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> <456B5BDC.6030805@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1869F7C7-057B-4738-B24F-1336E9C8F72F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 09:51:21 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Joel M. Halpern" , SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 27, 2006, at 3:42 PM, Paul Kyzivat wrote: > > IMO if the request has reached a UAS that is properly authenticated > as the intended recipient of the request, then the contract implied > by SIPS has been fulfilled, and what happens after that is out of > scope. Whether that UAS happens to be a gateway is irrelevant as > long as it has the proper credentials for the target address. > So if the CSCF is acting as a B2BUA (which it can sometimes do) it's OK to use IPSEC instead of TLS on hops behind that CSCF, even though a SIPS: URI was used to initiate the request? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 11:04:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5Qg-00025v-K8; Tue, 28 Nov 2006 11:03:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5Qf-000247-2y for sip@ietf.org; Tue, 28 Nov 2006 11:03:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5Qc-0000ob-Nv for sip@ietf.org; Tue, 28 Nov 2006 11:03:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 08:03:26 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kASG3PE2023158; Tue, 28 Nov 2006 11:03:25 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kASG3OYN001122; Tue, 28 Nov 2006 11:03:25 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 11:03:24 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 11:03:24 -0500 Message-ID: <456C5DCC.4040503@cisco.com> Date: Tue, 28 Nov 2006 11:03:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Re: SIPS and the PSTN References: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> <456B5BDC.6030805@cisco.com> <1869F7C7-057B-4738-B24F-1336E9C8F72F@softarmor.com> In-Reply-To: <1869F7C7-057B-4738-B24F-1336E9C8F72F@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 16:03:24.0465 (UTC) FILETIME=[BBC9E210:01C71306] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1036; t=1164729805; x=1165593805; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20 |To:=20Dean=20Willis=20; bh=XYMnTQYFIJTSvix+/sYKwAOxTuPZo7DORFiAlLimZtQ=; b=n/yezkakL9Hb+ri4m59NVTbJg52F6ccYx2gKaOsFgLwvllIYlJM9dSsNPDeNAKCadccMtMB8 dy5nUw2X1U1lX2Bwi/YrJVOG7lhe/v4t6Up1VwTVXo7z58AMI+KgzSYu; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Joel M. Halpern" , SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Nov 27, 2006, at 3:42 PM, Paul Kyzivat wrote: > >> >> IMO if the request has reached a UAS that is properly authenticated as >> the intended recipient of the request, then the contract implied by >> SIPS has been fulfilled, and what happens after that is out of scope. >> Whether that UAS happens to be a gateway is irrelevant as long as it >> has the proper credentials for the target address. >> > > So if the CSCF is acting as a B2BUA (which it can sometimes do) it's OK > to use IPSEC instead of TLS on hops behind that CSCF, even though a > SIPS: URI was used to initiate the request? The answer to that depends on the purpose of the B2BUA. My SIPS connection is with it. What is appropriate for it to do is up to it to decide. If I don't trust it to decide then I shouldn't call it. In some cases (e.g. the fabled "transparent" B2BUA) it may be that the only thing that makes sense on the other side is SIPS again. In other cases UDP may be reasonable. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 11:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5bd-0005ZA-QO; Tue, 28 Nov 2006 11:14:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5bb-0005Y6-Ch for sip@ietf.org; Tue, 28 Nov 2006 11:14:47 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5bY-0003Lu-4p for sip@ietf.org; Tue, 28 Nov 2006 11:14:47 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASGEe914451; Tue, 28 Nov 2006 11:14:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 10:14:17 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2C902B@zrc2hxm0.corp.nortel.com> In-Reply-To: <456C5DCC.4040503@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccTBwEbLX2iYaiXSQKptHLFvz/Z6wAAMKmg From: "Francois Audet" To: "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Joel M. Halpern" , SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Let's try to write up something for the document. I am pretty sure that I remember that in essence, what we decided was that: 1) Anything outside SIP network is out-of-scope 2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that there ain't nothing we can do to enforce it of course). Here is a strawman: 3.1. Scope of SIPS It is outside of the scope of this document to specify what happens when a SIPS URI defines a UAS that "maps" outside of the SIP network. For example, to other networks such as the PSTN or an H.323 network. These networks have their own standards on what is appropriate security levels. Derived connections in SIP however should use SIPS end-to-end, even accross distinct SIP networks. For example, If a Back-to-Back-User- Agent (B2BUA) receives a request destined to a SIPS Request-URI and it forwards it, it should use a SIPS Request-URI on the outgoing connection as well. This could happen for example when the B2BUA is Session Border Controller sitting between two SIP networks. It could also happen in an Application Server or with SIP third-party call control [RFC3725]. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 11:37:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5wt-0003k3-72; Tue, 28 Nov 2006 11:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5wr-0003b9-Q7 for sip@ietf.org; Tue, 28 Nov 2006 11:36:45 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5wq-0007IG-Hi for sip@ietf.org; Tue, 28 Nov 2006 11:36:45 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1Gp5wd-0001cb-R3; Tue, 28 Nov 2006 08:36:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 08:36:29 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC5D4111@sea02-mxc01.citel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C902B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTBwEbLX2iYaiXSQKptHLFvz/Z6wAAMKmgAABL2PA= From: "Michael Procter" To: "Francois Audet" , "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Joel M. Halpern" , SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > Let's try to write up something for the document. > I am pretty sure that I remember that in essence, what we > decided was that: > 1) Anything outside SIP network is out-of-scope > 2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that > there ain't nothing we can do to enforce it of course). I think that the second point is arguable, and depends on exactly what function the B2BUA is performing. And I also think that this is what Paul Kyzivat was describing when he wrote: # IMO if the request has reached a UAS that is properly authenticated as # the intended recipient of the request, then the contract implied by SIPS=20 # has been fulfilled, and what happens after that is out of scope. If I send a request to sips:alice@example.com, which arrives at a B2BUA and is subsequently retargeted to sip:alice@alicepc.example.com, then I think the change from sips to sip is fair - I wanted to reach the AoR (sips:alice@example.com) using sips, which I have done. If, on the other hand, I send a request to sips:alice@alicepc.example.com, which happens to transit a B2BUA en-route, then changing from sips to sip is not fair - I have not reached my target in the manner that I have requested. The distinction is, of course, that in the first case, the B2BUA was the target of my request, but in the second it was merely a transit point. Requiring SIPS to SIPS for the latter is an excellent move, but I am not convinced about requiring it for the former. Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 11:42:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp61x-0007kI-MA; Tue, 28 Nov 2006 11:42:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp61w-0007k6-QF for sip@ietf.org; Tue, 28 Nov 2006 11:42:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp61u-0007px-Eo for sip@ietf.org; Tue, 28 Nov 2006 11:42:00 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 28 Nov 2006 08:41:58 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kASGfvcR005894; Tue, 28 Nov 2006 08:41:57 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kASGfvOV007613; Tue, 28 Nov 2006 08:41:57 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 11:41:55 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 11:41:54 -0500 Message-ID: <456C66D1.4080600@cisco.com> Date: Tue, 28 Nov 2006 11:41:53 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Re: SIPS and the PSTN References: <1ECE0EB50388174790F9694F77522CCF0E2C902B@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C902B@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 16:41:54.0452 (UTC) FILETIME=[1CA5ED40:01C7130C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1675; t=1164732117; x=1165596117; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20; bh=LlthDv+cdFDBU8bVhrTOURPhPuIeXTATHIHn/6y5rfw=; b=S2PpZNoMURQ3UhJOd3UTccE5nqI0zjXMaqIVLz28Elx/rDYnmusxURQC91y2lXZB75eayc58 kRb5VsNKQT0AUWHPiERpPneA+mJPSuzdGhff1lnh0F/6UyjUNzqkZvmj; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Joel M. Halpern" , SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think I am ok with SHOULD for B2BUAs, but I still think it is hard to be specific because of the wide variety of things that B2BUAs can do. Consider a different kind of B2BUA - a conference focus. If it allows connections via SIPS, should it require all connections to be SIPS? While that might be a policy for some conferences, I don't think it is the only reasonable policy. Paul Francois Audet wrote: > Let's try to write up something for the document. > I am pretty sure that I remember that in essence, what we > decided was that: > 1) Anything outside SIP network is out-of-scope > 2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that > there ain't nothing we > can do to enforce it of course). > > Here is a strawman: > > 3.1. Scope of SIPS > > It is outside of the scope of this document to specify what happens > when a SIPS URI defines a UAS that "maps" outside of the SIP network. > For example, to other networks such as the PSTN or an H.323 network. > These networks have their own standards on what is appropriate > security levels. > > Derived connections in SIP however should use SIPS end-to-end, even > accross distinct SIP networks. For example, If a Back-to-Back-User- > Agent (B2BUA) receives a request destined to a SIPS Request-URI and > it forwards it, it should use a SIPS Request-URI on the outgoing > connection as well. This could happen for example when the B2BUA is > Session Border Controller sitting between two SIP networks. It could > also happen in an Application Server or with SIP third-party call > control [RFC3725]. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 12:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6Zu-0006LX-AP; Tue, 28 Nov 2006 12:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6Zs-0006LL-Ay for sip@ietf.org; Tue, 28 Nov 2006 12:17:04 -0500 Received: from web52911.mail.yahoo.com ([206.190.49.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gp6Zr-0004lz-2e for sip@ietf.org; Tue, 28 Nov 2006 12:17:04 -0500 Received: (qmail 81532 invoked by uid 60001); 28 Nov 2006 17:17:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dQ0DPI6WxOtEneAofgBXM8XBv55U0z7F73ccxFzDcdsYqGsPjSg5mVU6ALCUwGbBZTF/UT5Vvk5O3Iks00tGPfi85UaHeJnAu3AJnzp8Iw1z/LcxTsNkFJF4nW72RdP7+GYEO3CvIWRpdCsFMll9xlik3tegVPTgq82Qlcw8YDk=; X-YMail-OSG: 9Xv8nW4VM1mqOpmmqc4tyqcdx25g.dGZeUr.tHQcYlNVgniXpY0abQFUhVQTKdc1OhXZM_MvG0hbMEgL33XbDodi56gt7oCcIld_8OKcg4JqMfmiaqNFZp6twLTYcyn4BTspdQ2ZaPO5SwM- Received: from [217.33.106.234] by web52911.mail.yahoo.com via HTTP; Tue, 28 Nov 2006 09:17:02 PST Date: Tue, 28 Nov 2006 09:17:02 -0800 (PST) From: Raj To: SIP forum , sip@ietf.org, sip-implementors@cs.columbia.edu MIME-Version: 1.0 Message-ID: <756659.80989.qm@web52911.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Sip] Forking INVITE SIP message - regarding X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1679687832==" Errors-To: sip-bounces@ietf.org --===============1679687832== Content-Type: multipart/alternative; boundary="0-1788767601-1164734222=:80989" Content-Transfer-Encoding: 8bit --0-1788767601-1164734222=:80989 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Consider the following situation. Adam wants to call Bob, let’s say that Bob is registered at three locations, that is, at home, at head office and at his branch office. Hence, when Adam makes a call, INVITE request is forked by the proxy and it reaches all the three destinations. Hence, three 200 OK SIP response will be sent back to Adam. Consider the situation, when Bob’s friends answer the call at all the three locations at the same time, what will happen? Either three media channel will be established between them or which two will be discarded. Can anyone please clear this? With regards Raj. --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. --0-1788767601-1164734222=:80989 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
Consider the following situation.
 
            Adam wants to call Bob, let’s say that Bob is registered at three locations, that is, at home, at head office and at his branch office. Hence, when Adam makes a call, INVITE request is forked by the proxy and it reaches all the three destinations. Hence, three 200 OK SIP response will be sent back to Adam. 
 
            Consider the situation, when Bob’s friends answer the call at all the three locations at the same time, what will happen? Either three media channel will be established between them or which two will be discarded.
 
            Can anyone please clear this?
 
With regards
Raj.

Everyone is raving about the all-new Yahoo! Mail beta. --0-1788767601-1164734222=:80989-- --===============1679687832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1679687832==-- From sip-bounces@ietf.org Tue Nov 28 12:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6w6-0002Om-0U; Tue, 28 Nov 2006 12:40:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6w4-0002OR-A5 for sip@ietf.org; Tue, 28 Nov 2006 12:40:00 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp6w2-0000wb-Vw for sip@ietf.org; Tue, 28 Nov 2006 12:40:00 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 09:39:58 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kASHdvD3024598; Tue, 28 Nov 2006 12:39:57 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASHdvDM011510; Tue, 28 Nov 2006 12:39:57 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 12:39:57 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 12:39:56 -0500 Message-ID: <456C746C.5050305@cisco.com> Date: Tue, 28 Nov 2006 12:39:56 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Raj References: <756659.80989.qm@web52911.mail.yahoo.com> In-Reply-To: <756659.80989.qm@web52911.mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Nov 2006 17:39:56.0901 (UTC) FILETIME=[38597950:01C71314] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1258; t=1164735597; x=1165599597; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip-implementors]=20Forking=20=20INVITE=20SIP=20mess age=20-=20regarding |Sender:=20 |To:=20Raj=20; bh=j3/lt6KiACFeEJ985d6KhdyYsa6yVal1pZYZNMrtOxE=; b=jyv3dconxNG2V9Qrqrh9qoCYS6vswAqY1Q2Um6LpBqt9b/+m+QWLvWJd/3KFQfetlGiXyVYE 1dJImuArg5JHMI5lMk+lUi8dJn1K5rTs/BR6tESq1bq49kTt+7pqs0c4; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, SIP forum , sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Forking INVITE SIP message - regarding X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Raj wrote: > Hello, > > Consider the following situation. > > Adam wants to call Bob, let’s say that Bob is registered at three locations, that is, at home, at head office and at his branch office. Hence, when Adam makes a call, INVITE request is forked by the proxy and it reaches all the three destinations. Hence, three 200 OK SIP response will be sent back to Adam. > > Consider the situation, when Bob’s friends answer the call at all the three locations at the same time, what will happen? Either three media channel will be established between them or which two will be discarded. > > Can anyone please clear this? While all three locations may ring at once, its unlikely that all three with answer at exactly the same time. As long as one answers first be a second of so, the proxy will cancel the others and they won't send a 200 response. Its only when multiple phones are answered in the small time window where they can't be canceled that you get multiple 200 replies. If that happens, its up to Adam's UA to decide what to do. While it *could* conference them all together, a common strategy is simply to send a BYE to all except the first. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 12:48:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp73W-0006Hg-UT; Tue, 28 Nov 2006 12:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp73V-0006Hb-CC for sip@ietf.org; Tue, 28 Nov 2006 12:47:41 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp73U-0001td-2U for sip@ietf.org; Tue, 28 Nov 2006 12:47:41 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASHlW111584; Tue, 28 Nov 2006 12:47:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 11:46:56 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2C925A@zrc2hxm0.corp.nortel.com> In-Reply-To: <456C66D1.4080600@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccTDCHcslKnkykZQ9qKIBKMlB4vEgACMcFw From: "Francois Audet" To: "Paul Kyzivat" , "Michael Procter" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Joel M. Halpern" , SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agreed, that's why it's a should, and that's why that section is short... Are we OK with the wording? And remember: concrete proposals... =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, November 28, 2006 08:42 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; Joel M. Halpern; SIP WG > Subject: Re: [Sip] Re: SIPS and the PSTN >=20 > I think I am ok with SHOULD for B2BUAs, but I still think it=20 > is hard to be specific because of the wide variety of things=20 > that B2BUAs can do. >=20 > Consider a different kind of B2BUA - a conference focus. If=20 > it allows connections via SIPS, should it require all=20 > connections to be SIPS?=20 > While that might be a policy for some conferences, I don't=20 > think it is the only reasonable policy. >=20 > Paul >=20 > Francois Audet wrote: > > Let's try to write up something for the document. > > I am pretty sure that I remember that in essence, what we=20 > decided was=20 > > that: > > 1) Anything outside SIP network is out-of-scope > > 2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that=20 > > there ain't nothing we > > can do to enforce it of course). > >=20 > > Here is a strawman: > >=20 > > 3.1. Scope of SIPS > >=20 > > It is outside of the scope of this document to specify=20 > what happens > > when a SIPS URI defines a UAS that "maps" outside of the=20 > SIP network. > > For example, to other networks such as the PSTN or an=20 > H.323 network. > > These networks have their own standards on what is appropriate > > security levels. > >=20 > > Derived connections in SIP however should use SIPS=20 > end-to-end, even > > accross distinct SIP networks. For example, If a=20 > Back-to-Back-User- > > Agent (B2BUA) receives a request destined to a SIPS=20 > Request-URI and > > it forwards it, it should use a SIPS Request-URI on the outgoing > > connection as well. This could happen for example when=20 > the B2BUA is > > Session Border Controller sitting between two SIP=20 > networks. It could > > also happen in an Application Server or with SIP third-party call > > control [RFC3725]. > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 13:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7Vs-00043i-Cm; Tue, 28 Nov 2006 13:17:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7Vq-00043V-Oc for sip@ietf.org; Tue, 28 Nov 2006 13:16:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp7Vp-0005pD-Aa for sip@ietf.org; Tue, 28 Nov 2006 13:16:58 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 28 Nov 2006 10:16:56 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kASIGtJ4026200; Tue, 28 Nov 2006 13:16:55 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASIGrDM000280; Tue, 28 Nov 2006 13:16:53 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:16:53 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:16:52 -0500 Message-ID: <456C7D14.5000604@cisco.com> Date: Tue, 28 Nov 2006 13:16:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Michael Procter Subject: Re: [Sip] Re: SIPS and the PSTN References: <76431CABEC5EED489807DB8AEBCCA0BC5D4111@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BC5D4111@sea02-mxc01.citel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 18:16:52.0881 (UTC) FILETIME=[612D3010:01C71319] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3550; t=1164737816; x=1165601816; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20 |To:=20Michael=20Procter=20; bh=bvWwxvCZ1OQ04Au/WZhpLEFythuqGaoSDAXw06ytpno=; b=cPaNe3Tm+gJpUk7RxaGzHTNAD3HvBFkKbd/qn+HbmT/UOpifFTHM3jIQg50qqPsuZ55j5NTm fQp1Dwa+ZdFGfCRc7biqWoMGoEA4UOrvD/ZDKFEfJpdLqM9Br8sfNrll; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "Joel M. Halpern" , SIP WG , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael Procter wrote: > Francois Audet wrote: >> Let's try to write up something for the document. >> I am pretty sure that I remember that in essence, what we >> decided was that: >> 1) Anything outside SIP network is out-of-scope >> 2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that >> there ain't nothing we can do to enforce it of course). > > I think that the second point is arguable, and depends on exactly what > function the B2BUA is performing. And I also think that this is what > Paul Kyzivat was describing when he wrote: > > # IMO if the request has reached a UAS that is properly authenticated as > > # the intended recipient of the request, then the contract implied by > SIPS > # has been fulfilled, and what happens after that is out of scope. > > If I send a request to sips:alice@example.com, which arrives at a B2BUA > and is subsequently retargeted to sip:alice@alicepc.example.com, then I > think the change from sips to sip is fair - I wanted to reach the AoR > (sips:alice@example.com) using sips, which I have done. > > If, on the other hand, I send a request to > sips:alice@alicepc.example.com, which happens to transit a B2BUA > en-route, then changing from sips to sip is not fair - I have not > reached my target in the manner that I have requested. > > The distinction is, of course, that in the first case, the B2BUA was the > target of my request, but in the second it was merely a transit point. > Requiring SIPS to SIPS for the latter is an excellent move, but I am not > convinced about requiring it for the former. I was thinking of bringing this up. The trick is determining if the B2BUA is the target of the request or not. This isn't an easy question to answer based on info in 3261. Ignoring for now the new proposal for loose routing for UAs, I have been thinking that a server should determine if it is the UAS for a request by first removing any Route headers that refer to it. After that, it should only act as a UAS if there are no Route headers and the R-URI identifies the server. If there are Route headers that don't refer to it, or the R-URI doesn't refer to it, then it can either act as a proxy/redirect server, or else it can simply return an error. BUT I find nothing saying to do any of that. In 8.2 of 3261 there is no mention of checking either Route headers or the R-URI. I'm not sure if this is intended, or is an oversight. (Of course with loose routing for UAs this would change. In that case, I guess all leading Route headers referring to the server should be removed. If the last of these had ";lr" then the R-URI need not reference the server and instead identifies the intended callee. If there were no Route headers removed, or if the last one didn't have ";lr", then validation should be the old way.) If one then introduces B2BUAs into this picture, you need a somewhat modified set of rules. In a case that would otherwise require acting as a proxy, it might be permissible to act as a "transit B2BUA", terminating the incoming request but generating another on the other side, preserving the R-URI and the remainder of the Route. With such a set of rules, I think it would make sense that SIPS be preserved across such a "transit B2BUA". Conversely, if the request terminates on the B2BUA without any further routing specified, but the B2BUA chooses to route it on anyway, then preservation of SIPS would be at the discretion of the B2BUA. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 13:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7x8-0004ee-1j; Tue, 28 Nov 2006 13:45:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7x2-0004bV-Hx for sip@ietf.org; Tue, 28 Nov 2006 13:45:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp7us-0001Uc-D2 for sip@ietf.org; Tue, 28 Nov 2006 13:42:52 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 10:42:49 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kASIgmBm014699; Tue, 28 Nov 2006 13:42:48 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASIgkDO015358; Tue, 28 Nov 2006 13:42:46 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:42:46 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:42:46 -0500 Message-ID: <456C8325.60909@cisco.com> Date: Tue, 28 Nov 2006 13:42:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Re: SIPS and the PSTN References: <1ECE0EB50388174790F9694F77522CCF0E2C925A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C925A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 18:42:46.0306 (UTC) FILETIME=[FF170820:01C7131C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4972; t=1164739368; x=1165603368; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20 |To:=20Francois=20Audet=20; bh=0Y+fsNGW2Y/Y7gKcYO1byyu4IBvaaFWrdI3WuutpIPA=; b=WrkM/ls0vNqi6s5iGNiyPv/Ps77X2tPMSoFtM4gNI/Erdie+SLtjyjhdY6Sod+KSrSZ9udQa Dae6j4CSAJV0TZJgJTGPCB3VBsWJS9TPVeZsMdSfnM8Yf1saMhtUgQMM; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Joel M. Halpern" , SIP WG , Michael Procter , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > Agreed, that's why it's a should, and that's why that section is > short... > > Are we OK with the wording? > > And remember: concrete proposals... I just posted some further thoughts on this. I think they are interesting, but probably beyond the scope of this document. (It may be getting to the point where we actually need another document to discuss kinds of B2BUAs and expected behaviors for them. But I wouldn't want to hold this document up for that.) Here is a slight modification to your proposal, for consideration: > 3.1. Scope of SIPS > > It is outside of the scope of this document to specify what happens > when a SIPS URI defines a UAS that "maps" outside of the SIP network. ^^^^^^^ identifies > For example, to other networks such as the PSTN or an H.323 network. > These networks have their own standards on what is appropriate > security levels. > > Derived connections in SIP however should use SIPS end-to-end, even > accross distinct SIP networks. For example, I am not sure what the above means. What is a "derived connection"? I think that part could simply be omitted without loss, though I would not object to something a little clearer. > If a Back-to-Back-User- > Agent (B2BUA) receives a request destined to a > SIPS Request-URI ^ ^ that does not identify itself > and it forwards it, ^ on towards that Request-URI > it should use a SIPS Request-URI on the outgoing ^^^^^^ SHOULD > connection as well. This could happen for example when the B2BUA is > Session Border Controller sitting between two SIP networks. It could > also happen in an Application Server or with SIP third-party call > control [RFC3725]. Putting that all together it comes out as: 3.1. Scope of SIPS It is outside of the scope of this document to specify what happens when a SIPS URI identifies a UAS that "maps" outside of the SIP network. For example, to other networks such as the PSTN or an H.323 network. These networks have their own standards on what is appropriate security levels. If a Back-to-Back-User-Agent (B2BUA) receives a request destined to a SIPS Request-URI that does not identify itself and it forwards it on towards that Request-URI, it SHOULD use a SIPS Request-URI on the outgoing connection as well. This could happen for example when the B2BUA is a Session Border Controller sitting between two SIP networks. It could also happen in an Application Server or with SIP third-party call control [RFC3725]. Paul >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, November 28, 2006 08:42 >> To: Audet, Francois (SC100:3055) >> Cc: Dean Willis; Joel M. Halpern; SIP WG >> Subject: Re: [Sip] Re: SIPS and the PSTN >> >> I think I am ok with SHOULD for B2BUAs, but I still think it >> is hard to be specific because of the wide variety of things >> that B2BUAs can do. >> >> Consider a different kind of B2BUA - a conference focus. If >> it allows connections via SIPS, should it require all >> connections to be SIPS? >> While that might be a policy for some conferences, I don't >> think it is the only reasonable policy. >> >> Paul >> >> Francois Audet wrote: >>> Let's try to write up something for the document. >>> I am pretty sure that I remember that in essence, what we >> decided was >>> that: >>> 1) Anything outside SIP network is out-of-scope >>> 2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that >>> there ain't nothing we >>> can do to enforce it of course). >>> >>> Here is a strawman: >>> >>> 3.1. Scope of SIPS >>> >>> It is outside of the scope of this document to specify >> what happens >>> when a SIPS URI defines a UAS that "maps" outside of the >> SIP network. >>> For example, to other networks such as the PSTN or an >> H.323 network. >>> These networks have their own standards on what is appropriate >>> security levels. >>> >>> Derived connections in SIP however should use SIPS >> end-to-end, even >>> accross distinct SIP networks. For example, If a >> Back-to-Back-User- >>> Agent (B2BUA) receives a request destined to a SIPS >> Request-URI and >>> it forwards it, it should use a SIPS Request-URI on the outgoing >>> connection as well. This could happen for example when >> the B2BUA is >>> Session Border Controller sitting between two SIP >> networks. It could >>> also happen in an Application Server or with SIP third-party call >>> control [RFC3725]. >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 14:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8Dx-0004se-GC; Tue, 28 Nov 2006 14:02:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8Dw-0004sY-4i for sip@ietf.org; Tue, 28 Nov 2006 14:02:32 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp8Du-0004n7-Ov for sip@ietf.org; Tue, 28 Nov 2006 14:02:32 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASJ2M123721; Tue, 28 Nov 2006 14:02:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 13:02:10 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2C941B@zrc2hxm0.corp.nortel.com> In-Reply-To: <456C8325.60909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccTHQPjkyMyVyYbR22+HKJo+1BzwwAAp75A From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: "Joel M. Halpern" , SIP WG , Michael Procter , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm ok with your wording. Thanks.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, November 28, 2006 10:43 > To: Audet, Francois (SC100:3055) > Cc: Michael Procter; Dean Willis; Joel M. Halpern; SIP WG > Subject: Re: [Sip] Re: SIPS and the PSTN >=20 >=20 >=20 > Francois Audet wrote: > > Agreed, that's why it's a should, and that's why that section is=20 > > short... > >=20 > > Are we OK with the wording? > >=20 > > And remember: concrete proposals... >=20 > I just posted some further thoughts on this. I think they are=20 > interesting, but probably beyond the scope of this document.=20 > (It may be getting to the point where we actually need=20 > another document to discuss kinds of B2BUAs and expected=20 > behaviors for them. But I wouldn't want to hold this document=20 > up for that.) >=20 > Here is a slight modification to your proposal, for consideration: >=20 > > 3.1. Scope of SIPS > >=20 > > It is outside of the scope of this document to specify=20 > what happens > > when a SIPS URI defines a UAS that "maps" outside of the=20 > SIP network. > ^^^^^^^ > identifies >=20 > > For example, to other networks such as the PSTN or an=20 > H.323 network. > > These networks have their own standards on what is appropriate > > security levels. > >=20 > > Derived connections in SIP however should use SIPS=20 > end-to-end, even > > accross distinct SIP networks. For example, >=20 > I am not sure what the above means. What is a "derived=20 > connection"? I think that part could simply be omitted=20 > without loss, though I would not object to something a little clearer. >=20 > > If a Back-to-Back-User- > > Agent (B2BUA) receives a request destined to a > > SIPS Request-URI > ^ =20 > ^ > that does not identify itself >=20 > > and it forwards it, > ^ > on towards that Request-URI >=20 > > it should use a SIPS Request-URI on the outgoing > ^^^^^^ > SHOULD >=20 > > connection as well. This could happen for example when=20 > the B2BUA is > > Session Border Controller sitting between two SIP=20 > networks. It could > > also happen in an Application Server or with SIP third-party call > > control [RFC3725]. >=20 > Putting that all together it comes out as: >=20 > 3.1. Scope of SIPS >=20 > It is outside of the scope of this document to specify what > happens when a SIPS URI identifies a UAS that "maps" outside > of the SIP network. >=20 > For example, to other networks such as the PSTN or an=20 > H.323 network. > These networks have their own standards on what is appropriate > security levels. >=20 > If a Back-to-Back-User-Agent (B2BUA) receives a request > destined to a SIPS Request-URI that does not identify itself > and it forwards it on towards that Request-URI, it SHOULD use > a SIPS Request-URI on the outgoing connection as well. This > could happen for example when the B2BUA is a Session Border > Controller sitting between two SIP networks. It could also > happen in an Application Server or with SIP third-party call > control [RFC3725]. >=20 > Paul >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Tuesday, November 28, 2006 08:42 > >> To: Audet, Francois (SC100:3055) > >> Cc: Dean Willis; Joel M. Halpern; SIP WG > >> Subject: Re: [Sip] Re: SIPS and the PSTN > >> > >> I think I am ok with SHOULD for B2BUAs, but I still think=20 > it is hard=20 > >> to be specific because of the wide variety of things that=20 > B2BUAs can=20 > >> do. > >> > >> Consider a different kind of B2BUA - a conference focus.=20 > If it allows=20 > >> connections via SIPS, should it require all connections to be SIPS? > >> While that might be a policy for some conferences, I don't=20 > think it=20 > >> is the only reasonable policy. > >> > >> Paul > >> > >> Francois Audet wrote: > >>> Let's try to write up something for the document. > >>> I am pretty sure that I remember that in essence, what we > >> decided was > >>> that: > >>> 1) Anything outside SIP network is out-of-scope > >>> 2) B2BUA SHOULD preserve SIPS on both sides. (It was also=20 > said that=20 > >>> there ain't nothing we > >>> can do to enforce it of course). > >>> > >>> Here is a strawman: > >>> > >>> 3.1. Scope of SIPS > >>> > >>> It is outside of the scope of this document to specify > >> what happens > >>> when a SIPS URI defines a UAS that "maps" outside of the > >> SIP network. > >>> For example, to other networks such as the PSTN or an > >> H.323 network. > >>> These networks have their own standards on what is appropriate > >>> security levels. > >>> > >>> Derived connections in SIP however should use SIPS > >> end-to-end, even > >>> accross distinct SIP networks. For example, If a > >> Back-to-Back-User- > >>> Agent (B2BUA) receives a request destined to a SIPS > >> Request-URI and > >>> it forwards it, it should use a SIPS Request-URI on=20 > the outgoing > >>> connection as well. This could happen for example when > >> the B2BUA is > >>> Session Border Controller sitting between two SIP > >> networks. It could > >>> also happen in an Application Server or with SIP=20 > third-party call > >>> control [RFC3725]. > >>> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 15:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Mn-0003Jw-8M; Tue, 28 Nov 2006 15:15:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Ml-0003DQ-F8 for sip@ietf.org; Tue, 28 Nov 2006 15:15:43 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9Mh-0007N4-Sd for sip@ietf.org; Tue, 28 Nov 2006 15:15:43 -0500 Received: from dhcp89-089-076.bbn.com ([128.89.89.76] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Gp9Mh-0004vS-54 for sip@ietf.org; Tue, 28 Nov 2006 15:15:39 -0500 Message-ID: <456C98EA.2040801@bbn.com> Date: Tue, 28 Nov 2006 15:15:38 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP WG Subject: Re: [Sip] Re: SIPS and the PSTN (Meeting Audio) References: <097F22C9-F104-48A6-933C-770E7946A90C@softarmor.com> <7.0.1.0.0.20061126203626.03547698@stevecrocker.com> <456B5BDC.6030805@cisco.com> <4B9D0728-E7F0-4F0A-9781-D369A957EC38@cisco.com> In-Reply-To: <4B9D0728-E7F0-4F0A-9781-D369A957EC38@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There appeared to be some confusion regarding the proposed minutes (specifically discussion on the 4th Point of Dean's Trial Balloon) and the concensus on SIPS and the PSTN. Therefore, I went back to the audio stream and collected the comments made regarding the points of Dean's proposal. One point of note is that no one present at the meeting appeared to supported the idea that a SIPS call fail when it hits a PSTN gateway. The audio recording can be obtained at: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch8-thu-noon.mp3 To aid anyone else who wants to listen to the audio stream, the number next to each comment is the time (relative to the start of the audio stream, represented as Hours:Minutes:Seconds) that the comment was made. (I apologize to the speakers whose names I didn't catch and of course for any transcription errors in the following.) [2:41:00] Francois begins his explanation of the four points of Dean's Trail Balloon Proposal. [2:44:40] Question from Jabber Channel: Does Point 2 mean all hops are TLS? Answer: Yes [2:45:30] Explanation of why the functionality provided by SIPS is important. [Not directly related to Point 4] [2:47:45] Eric Burger says that we should remove Point 4. "Take the whole thing out [referring to Point 4] ... Unless it's really end-to-end it's like a non-solvable problem. 'It' being not just to a PSTN gateway, but to another IP gateway or whatever. If it is to a PSTN gateway that does terminate to a PSTN phone then actually the SIPS thing, the promise, was kept and if it's a gateway to another SIP thing then it is not kept ... Just don't mention PSTN termination" [2:48:40] Question to Eric: "What about other protocols that you might gateway to?" Eric's Answer: "It's a non-solvable problem." Therefore, delete bullet 4. [2:48:50] Paul Kyzivat begins, "I've said all I want to say about 4, I'm not going to say anymore." He then argues against bullet 1 being a SHOULD. "I just don't believe that most of the time it's going to be done. And if it isn't going to be done most of the time then putting the SHOULD in is just holding out a false promise to people." [2:49:45] Cullen Jennings comments on Points 1 and 4. On Point 1 he says "I think that we need to very clearly differentiate between what you to implement and what you need to use. As a general rule of thumb, on lots of our things here, we've tried to get people to implement security but not say that people necessarily have to use security." On Point 4 he says "I have a clear phrasing of what the commitment is, which is you're going to use TLS all the way to the UA. That's what I think it should be. Now my UA happens to be a speaker phone and I'm sitting in this room right now and there's a hundred people. I mean SIPS doesn't mean anything about what's going to happen on the other side of that speaker phone. I don't think it means anything about what's going to happen on the other side of that gateway. I don't think it means anything about what's going to happen on the other side of that protocol translator. Hopefully the protocol translater would do reasonable things, but it is impossible for us to specify beyond that point." [2:51:00] Question for Cullen: "Would you say that it's a best current practice for an SBC to terminate a SIPS connection and generate a SIP connection on the other side?" [2:51:15] Cullen replies: "I think that one of the most useful features that an SBC vender could offer today would be the one on the edge of an enterprise that could take unsecure phone calls from venders that hadn't managed to implement all of this stuff inside the enterprise and secure it as it crossed the internet. I think that's a great thing for people to go build. Needless to say the same thing needs to happen on incoming calls ... It doesn't matter what we say in these specifications though. Short of us breaking the PSTN there's no way to solve this ... We should not pretend that SIPS means anything beyond the UA." [2:52:15] New speaker comments on Points 1 and 4. On Point 1 he observes that in IMS you end up using SIPS over an IPSEC connection. Therefore, you're encrypting the signalling twice, once with TLS and once with IPSEC. He raises the question: Is it good for us to do that? On Point 4, he says that we cannot go into the PSTN and we should not go beyond the IP side gaurantees that SIPS can provide. [2:53:05] New speaker reminds everyone that it is Dean and not Francois that is to the source of this controversy. "The one thing that I would say about 4 is for certain forms of protocol interworking where we're dealing with something that's going from IP to IP, basically from one IP based protocol to another one, I wouldn't see the harm in having something that was a BCP have like a SHOULD level thing saying if there is a comparable sort of mechanism in that protocol than you should try to invoke it ... I think you would certainly want to fail it if that capability was available in the other protocol but not invokable ... I wouldn't be opposed to there being some language like that. For something like PSTN which is so dissimilar to the way that SIP operates, I don't think it's reasonable to expect that any of this carries over ... So, no number 1, please and a softer 4." [2:54:30] New speaker agrees with previous speaker. "That's exactly the same opinion that I had for PSTN and for similar networks." [2:54:45] New speaker points out that Brian Rosen (who is not present) is adamant that SIPS calls should fail if they reach a PSTN gateway. [2:54:55] Hadriel Kaplan agrees that Point 1 shouldn't be a SHOULD, "You can change it from a SHOULD to a MIGHT". He then comments on Point 4, "There's no question that SIPS is SIPS, it's part of SIP, not H.323, not PSTN, SS7, whatever. When you've reached the UAS, you've reached the UAS. You want to write a BCP, go right ahead, but the people who don't want to keep it SIPS or use SIPS or whatever will just ignore the BCP. For an SBC in particular ... As far as I know most of the SBC's that do support SIPS will obviously try to keep it SIPS on the other side of themselves. And, guess what, if the operator doesn't want them to, or says 'no you don't have to and you can use SIP', then they will do that because that's the whole concept of an SBC is that the operator decides ... I don't know the point of a BCP." He then goes on and argues that SIPS should not be deprecated. [2:56:45] Dean Willis addresses Hadriel's point on the need for a BCP. His analogy is that a BCP on operational recommendations for SIPS is analogous to a BCP on operating email systems that says 'don't be an open email relay'. [2:57:30] Hadriel says he understands but "It just seemed to me to be kind of funny, like writing a BCP that says 'Be Good'. The guys who don't won't to be good, won't be. There's no point in telling them to be good." [2:57:45] Dean says "It's more on the order of 'if you don't lock your doors, people can wander in through your doors'." [2:57:50] Hadriel says "Oh, you think that people might do it accidently ... You think they might just misconfigure ... I'm with you." [2:58:30] Jon Elwell comments on Point 4 "I agree with the majority, I think, that it has to stop at the UAS, whether that's a SIP gateway or a phone or a speaker phone or whatever. I'm a little bit concerned about the B2BUA case, particularly what you mentioned Dean. If a B2BUA SBC upgrades a SIP request to SIPS then I guess no harm is done. The other way around though is a bit worse ... We don't normally legislate for B2BUA's, that's the problem, so I don't know how we deal with this, but I'm a little bit uneasy about it." [2:59:20] Francois says, "I think the wording that Jon Peterson had actually applies here. It's a similar network. It's kind of two back-to-back SIP networks. It seems like a BCP-type thing." [2:59:30] Keith says, "My assumption of the point of this conversation is that basically we now reflect the pros and cons in the document." [2:59:45] Francois indicates that he has a sense from the room of what we heard. "[Point] 1 I think is some level of support but not that much. [Point] 4 I think we have a pretty good concesus except for one person who's not here. [Point] 3 is obvious, and [Point] 2 I think is ... implicitly I think that people like the idea of deprecating the last hop but we didn't really have a vote or anything on that." [3:00:20] Dean says "I think we have concensus on pretty much everything except for the fine-print writing of 4, and I think there's a fairly strong sense that number 1 is out of place and it just echos what's already in 3261. So I think we can reduce number 4 to a should level and explain the issues and do away with number 1 and I think everyone besides Brian Rosen will be happy." Cullen Jennings wrote: > > On Nov 27, 2006, at 1:42 PM, Paul Kyzivat wrote: >> The above seems to be a rehash of the prior on-list arguments made >> in support of this conclusion. >> >> IMO if the request has reached a UAS that is properly authenticated >> as the intended recipient of the request, then the contract implied >> by SIPS has been fulfilled, and what happens after that is out of >> scope. Whether that UAS happens to be a gateway is irrelevant as >> long as it has the proper credentials for the target address. >> >> Paul > > > I don't remember what the consensus was but I'm seem to recall making > a similar argument to Paul. Perhaps someone could listen to the audio > recordings of this and try and straight it out. I would be very > surprised if we had consensus that if one side of a IP to IP gateway > (such as protocol translator) was doing sips that the other side also > had to do sips. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 noskajcom@kosmic.org Tue Nov 28 16:20:55 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpANq-0002BR-VM for sip-archive@lists.ietf.org; Tue, 28 Nov 2006 16:20:55 -0500 Received: from chello085216222008.chello.sk ([85.216.222.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpANY-0000sz-Kr for sip-archive@lists.ietf.org; Tue, 28 Nov 2006 16:20:54 -0500 Received: from iVnWti ([144.184.17.191]) by soos with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Nov 2006 22:20:27 +0100 Message-ID: <000a01c71332$f2524940$00000000@aaaw8qrwdb4lcd> From: "nawafdcom nawinccom" To: sip-archive@lists.ietf.org Subject: piliernet pillcom pinglinet Date: Tue, 28 Nov 2006 22:19:53 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C7133B.5416B140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 0.3 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 ------=_NextPart_000_0006_01C7133B.5416B140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C7133B.5416B140" ------=_NextPart_001_0007_01C7133B.5416B140 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Isnflcom ispcom issaanpcom ististnet, istefcom iswattcom itbancacom. = Taroxnet tascarcom, tasiloncom tastevtcom tawaretcom taxronet, tbccycom. Tongasnet, toonearcom tooredcom tooringcom topcomcom. Sebemasnet = secnexcom secudocom secvalcom seelabcom seeshelcom. Zwxlcom zxrrcom zxhsnet zykjcom zypumpcom. Licknyccom licosercom lifeallnet, lifeamicom! Keyqscom keydicicom = keymancom keynartcom kezbocom kggkcom. Bonsai lxr faqsyou, project stable, finalised. Clubytecom cmapnetcom cmcapscom, cmeiconcom cmesoftcom cmhhomecom! Directory solaris sparc tarbz beos, mng localized volunteers mlp. = Xndbnrdcom xnfacom xngacom xnganet xnbhanet. Aodeccom aomtnet, aonomacom = aovancom apaqicom apaqinet apccom apgtechcom apnageocom. Gsdztcom gslywjcom gsmcallcom gstackcom gtszcom, gugacom guavonet, = guhornet. Aatdgcom aauidecom, abacoitnet abacomdnet? Mnbengcom mnotecom moonnet mocom moabcccom moagiftcom, mojjangcom = molognet. Ptcardscom ptfglscom, ptjzsjcom, ptlgrstcom ptnjlcom, ptolvincom = ptwxwbcom. Bigshipcom djnet, ktokcom laoscom manwellcom. Pic, hunter, nero wmv clone crack covers power. Jsyxhbcom juchoicom judithwcom jueshacom julencom, julianet julytcom = jumehnet, junbojccom. Xnganet, xnbhanet xnqbomcom xnfanet, xnzfanet, xnarnjanet xnarqjanet. = Wanalancom wandracom wandwebcom wangvucom wangzannet waouwnet wapaycom. = Bdhcnet bdjynet bdmswcom bezencom bearchcom? Vipixcom, vibedjscom = vicrecom videocom vietmoicom, vinhmomcom. Modern air pressure, = boilersrd. Bidders winners pick indicated winner bidder indicating. Wowescom, wowmagsnet wqkfcom wqxskycom. Xcqfcom xcqhcom xddjccom xdjcom. Biaosacom bichnoucom bidfirenet bidlaircom bifbvcom bigtallcom = bigdovecom. ------=_NextPart_001_0007_01C7133B.5416B140 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D"cncom"
Isnflcom ispcom issaanpcom ististnet, = istefcom=20 iswattcom itbancacom. Taroxnet tascarcom, tasiloncom tastevtcom = tawaretcom=20 taxronet, tbccycom.
Tongasnet, toonearcom tooredcom = tooringcom=20 topcomcom. Sebemasnet secnexcom secudocom secvalcom seelabcom = seeshelcom.
Zwxlcom zxrrcom zxhsnet zykjcom = zypumpcom.
Licknyccom licosercom lifeallnet, = lifeamicom!=20 Keyqscom keydicicom keymancom keynartcom kezbocom kggkcom.
Bonsai lxr faqsyou, project stable, = finalised.
Clubytecom cmapnetcom cmcapscom, = cmeiconcom=20 cmesoftcom cmhhomecom!
Directory solaris sparc tarbz beos, mng = localized=20 volunteers mlp. Xndbnrdcom xnfacom xngacom xnganet xnbhanet. Aodeccom = aomtnet,=20 aonomacom aovancom apaqicom apaqinet apccom apgtechcom = apnageocom.
Gsdztcom gslywjcom gsmcallcom gstackcom = gtszcom,=20 gugacom guavonet, guhornet. Aatdgcom aauidecom, abacoitnet = abacomdnet?
Mnbengcom mnotecom moonnet mocom = moabcccom=20 moagiftcom, mojjangcom molognet.
Ptcardscom ptfglscom, ptjzsjcom, = ptlgrstcom=20 ptnjlcom, ptolvincom ptwxwbcom.
Bigshipcom djnet, ktokcom laoscom = manwellcom.
Pic, hunter, nero wmv clone crack = covers power.
Jsyxhbcom juchoicom judithwcom = jueshacom julencom,=20 julianet julytcom jumehnet, junbojccom.
Xnganet, xnbhanet xnqbomcom xnfanet, = xnzfanet,=20 xnarnjanet xnarqjanet. Wanalancom wandracom wandwebcom wangvucom = wangzannet=20 waouwnet wapaycom. Bdhcnet bdjynet bdmswcom bezencom bearchcom? = Vipixcom,=20 vibedjscom vicrecom videocom vietmoicom, vinhmomcom. Modern air = pressure, boilersrd.
Bidders winners pick indicated winner = bidder indicating.
Wowescom, wowmagsnet wqkfcom wqxskycom. = Xcqfcom=20 xcqhcom xddjccom xdjcom.
Biaosacom bichnoucom bidfirenet = bidlaircom bifbvcom=20 bigtallcom bigdovecom.
------=_NextPart_001_0007_01C7133B.5416B140-- ------=_NextPart_000_0006_01C7133B.5416B140 Content-Type: image/gif; name="hzfwnet.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c71332$f2524940$00000000@aaaw8qrwdb4lcd> R0lGODlhrAEcAYcJAAAAAn8MDAB+AIiKCg4Mi4IBdQCDgbu4tMHSyKXE/DgeDFojAIcdAKggALgg AeItAAM9CBRGADhECmQ6AYA1AKROB7dOAN1AAAVeDCthAzZkDW1kBXdZBJ1YDLReDdpVAAl8AiKC AUmMAGV6Boh3BKOKArp/B+KJBgCaACOhAESrAGabBn2UAKmSBMqhCuiRAACyAC26BT3MAF24AHPK BZ3AAMK3BdKzAALfDiXWCUffAG7qCHfiAJrcAMrXAObpBwkAShQBSjUASWQAOI4NTqwDTboLNOsA OAkgOBoVQjgeRFMVSIQnNqwiMrcSPe4gSwA7RSBOSj40M2c/MXszTKA2RstISeE5MwxtSyVaS0xf R2BdNnVdBZhrOMBfSexgQgB2ThJ5R0V7SVF1QX6EPZmEQryCN9NxNAClOSieTjqlR12oRIOfSpyf ObioPeKtPADFTCe2MkWyRW7DRXG8PZ7ONrSxRN69SwDYNxjiTjbcS2nnMXnWQaDhQrzmMdfgTgAA dykEdDkAjWYAhXYAf5wEibYKd+wJjQsXfBYqiTQshGwpjXQefqsdjLIfeNsqcwY/ixVKe0tIiFU7 dIhEe51GjLJFi9c4iQ1eiyllhjJiiF5tjH9YfaFfis1cidpTdQaAgRx2hDVxc1uChnZ8gqJyeLKB hu53hACaiiOpgUqYfGyci4GniJeccc6qet6ieAC6diTAhDrFhWvDdIC3jZ6zebOzh9SydwLXjSjc cUzac1Hqc3TpjZPSesrSftvajQcDwxoAzjIGvVUAx4MAta4AwLEAtOsAvg4lshostEQfymodsooY saImvMEnst0hzgBNsyk8x0U6smFDwXVIuZpAx7w0st0/wwBrxCNguTRiu1lstndRuZdSybFXtelb tQByySGJxDSCwG5zy4WLwKB3vslyte17xwWnwh+oyUKZxlmhxYKnyZyTv8CsstaUswC2wiO0vDTB ylPEuYW+v6C7zv/v55Wlrnh9fv8OAADyDPb7AAAK8fUA/wD8+v/39CH5BAD//3kALAAAAACsARwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MjRor2PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPO7Mizp8+fQIMKHUq0qNGjSJMqXcq0qdOnQ3VKnUq1qtWrWLNq3cp1JdSvYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27eBd23cu3r9+/gAMLHky4sOHDiBMrppm3sePHkH8unky5 suXLmO1F3sy5s+fPoEOLjpy5tOnTqFMzHs26teuyqmPLnk378uvbuHPr3s27N1ybAQKIDG4vuHHj xY8LB0l8+HKSyj8qjz4d+vGQzbE/T37denTp28En/x+Zvbb584DLj1cvvr378SWzq5//vDxy8Mvv M89vP/z75uwBuB176BVoYFby8Wfdfs691+BJ9DEooYTdtUfgghT6l6CDB3booVQbwvegiBb6N2F8 4YVIIoPEbXghhiWSV5+CH9ZoI3Az4kddjs69yKF2I6oIZIs5+thjhQEOqN+NTKK3UXD/QCmQlAVJ SWWVATR03EFXRpmllwR1OWWWVn4JJZXKcfnlmGxi6aZvcIKFE5En7rfkiColeWSKJtIpnp9Aytig noE2aeihKQFKoIAouhRhoP0t2B+gdTpIqaUmIqppaRwZF+aanw4kJpgQdWnqmlee2uaYZb7pKpti qv8a56xO5bTkokoKCiGPhf4346+Y8perru5FiueJxm6q7F+dpjodmaCSKmq0anpqkKzTfmrtqtlO u2W133q7bajXguosrehitOy67LZrVbrwxivvvPTWS5e7+Oar70v29uvvvwAHLPDABBfsmE0CCBBS wgsrnPDDD9vDcMMSQxzxSBNTbLHCKWW8sccXf5SxyBzva/J5GSU8EMQrC/CPygfB/LLLMzckc8s1 C3QzQjsTBPPPNPfcs8FE+3TTxBCTrDRJIC+N0shKjwx1w1M7jTTHU1d98taoaQQ00DrTHLPLMg9t kNBki51zQmaXHXTaYxctN1pfvx32xj7f/LHaOBf/pLLefJ8d+No5/z242XMn7hHCDmPduNNMS13y SVk/DnlJVUOdNMNJX87156ZtxPLMbiv0cN42B2746Auh3frphQ+u+OwT4dR55xWbxHnJWotUee4t /a675VeDbvxposPOettig82Q64jzzHf0zkdP+/VJwX5334L3bT33sUe0M/V2h4/9+UsBnjfe46eN t/TLyz726OSv37z86Oev//789+///wAM4P6OR8AC1kiACEygAhfIwAY68IEQjGBHDEjBCppHghjM oAY3+BULevCDyOOgCHMDwhKacDIjTKEKV8hCiJzwhTCMoQxnSMMa2vCGOMyhDnfIwx7GpIVA7IwP /4dIxCIa0YdBTKISlxjBIzoRh0yMohSnyL8nWvGKWMyiFrfIkg98oItfbJcXm7QRAJjRjGDxokDU +A81evGNH1gjHNsIxzgSpI5xZCMb6fhGPvZxj3L8Yx8DaUc/FvKOdeSjHA15yEUOZI6OpONFIMnI R1LSko50YyL1mMdEFsSTnIykvNA4llBKEpCSNAgqRZlKU2ISkbD8ZCFN6cpXWtKOe1xlJGk5y0ZG pJaA1OUrQ4lKYvoylppMpTI9YxMzkuSMAPgINM8oTWiCxJr2mGY1t5nNaIJkjPYA5xjB+c0wioSc IUHnR+C4TnOW85zuVGc4w4jOcdLTne2Epz3fOf8Sctbzi+ysYznF+UZ4ptOc/sRnPue50H3q854n Ieg81SnPkzlTJBd1pkajuVFuXpOj3uxoNz3aTjyWNKH/JIlA+cnQh0L0oAldaD4l6tKTtvSmB2Up Q2O6U4gW1KAs5SlQJ7rSlcrUqDntqUIrarKLhiSjIB2pSKFKTahW06kqxeNLs6rTrh51qfhkKk1T itSu2lOoScWpQ1t61oJWNKVfTYlWt5pWpp70nmA9Hla52dG+hjSqUv3rVb1ZkrnKtJ8IVShObbrY xYr1pWQFqGIpKlm0BjWekuXnWg+rU6HadaBFBStNCxvWn3r1QBoh5UBIicbWAuAfrhVIbGH7Wtb/ vla2t8WtKnHZy4Tk8pjF5C0rg4sQV/KSlcts5W8PEkzhKtOYixQmMA+5yubuspHQleVwOxlLZt5E m920ql+pOVjAOhWre2VrYgPKztOadLQCfS97f9peol7WpZmd6GnValr9jpW+imWsWdsLV5S61aeh 5ex/mfQU1UbEwegTprwkLDcIP8TC56MwujR8MC56+MMgDnFqnILhgpSYikr8LjZZkt6RtFgl+cjH R2I8YxnH+MY2lrE9aIxjGos4ixk5MUOErNuJxFggR/7HkZM8kCQvOR8oxiCEbUvbaeL2jKvFMm2L 7BAnQ1nJUGZyk2+M5C9HOYLQLHJs13zb2bo5/7dd7rGXyTzmMdP5zEXTCVUF69dtipewL5Gzj30s EkIT+seIjsme/RzVPzNaJoLW8aFrPGgdJxrIHFGtpmvL6S1vmcpUjoiX60yQUYsZzwy0cpZXzWYt V7nNsJbIqMuMYzCXGcy1RrUEiazrXhuF10OJtLCH3WNfG/vYyE62smv3oUMc4irOxkq0L31C8GIU 0HyZ9kecrW2RcPvZ2+Y2SbptEm1/e9ritge5yU1tTQU51mE59z+cLRB6F8Te9Mb3IQxi74H0u97/ 9ve+8z3wfRMk4MtmSzP5XNW/LpqkNfk2SNAN7pBQ3NsVD/dI2M1xcEdb4hvPeLsR9W7danm2av+G t0a+LXCAH4TlBzd4zPkt85bfW+bcnnfNbZ7wtiycvOcFbHmxnROQXxzjGk860sN97oqvW+QaT7fS R05yjEw5tyj3tFBYrm+au1znCEG42HeOcJ0TnOc9B83VWQ3nUAM7Ilw3eNfBDvayf33mN8d73s9+ 97R/Zu0pt+2mOSJvgPf78Dk3e+L13nfFo93mi7e732HTbKgX3fJTYTfVydgZya985z3x/ORHT/rS m543XXmxYoi++SK+O80JebuJVV1yhcBZtqdX3NtlbxDeN0TIsNd67n2zcJSAF5tWdTGgkQ905j/8 vNl8avRb325rP1Ww1x+p9q/9TJBif6pC3z7/R68pTeq3fqPgL+9gS4Jeawad0e5n/Ucdrnrzhzi9 jtb+irnPV6Hn/6PGN33lZ3+JlnzZF1gepXrvh4D9p3/ht1fjR34EWIDkpXzNV4EKuHzxd30XSFjN N3/YJn8TOIL8p2cimBInSII1BBa+txDBNxG3N3wyOIP+ooI2eIM4uEM0uIMHkYM+aBs8GIQC8YNE WIRGeIRImIRKuIQ/JIRByIRQGIVSiDJOWIVWOHxTmIVVcYU0qIVeqBNcGIZiOIZkWIZmeIZomIZq uIZs2IZuCBRfGIdyOId0WIc3wg94iIcfkYd6uId8yA8gkYeBCIj2oId8WIh92IeIKIghwYiG//iH iOiHkriIiuiHjEiJj9iIkGiJmiiIfwiImziJdjgZiQiKhFiKJHGJmTiJjniKhJiKqFiJkTiLqwiL rPiKojiLIqGKuKiLtziIo3gVGYGHAkGMxPgPx3iMBGGM/FCMebiMzYiMz8iMCsGH0niN0OiM2qiM BpGM0ciN2KiNBUGN4SiOA6GM3viGQPGH4uiNz7iN3wiO7tiM5IgQ1siM7yiNn3iO+ciP7WiN5ciO 8MiP8xiP/liO6kgQNhGLh5iLkliKvciQmdiQwHiIsoiJlwiMnaiIsliJF1mLFRmRr4iKwbgYDKmL HfmJlKiJD+mJIymSK/mRn9iLvhiJHAmTGv85iKHYkrv4kg5ZkjkxjAaZjgiJjvR4lAfpjv84jvGI lN1okE/JlEuZjQdZlfLolEkZjQmpEAvZkDeJkShpii25iryYkbT4iBRJkpg4El+pkpDolj65iXCZ kRcJlDexlcdml3oJEnhpbHv5l4AJlEI5lfpIkPnIjkYpldiIj9M4lAIJjn3pG0RplFppjkWplVe5 lJl5jZAJmZHJG5PpmFSJkOG4menYme+Imp8JGTcxk3GJi1/ZkztpiXJJkWHJi4FJQ64Zkiz5k7G5 kV5Jk2HJlsKZmyW0mxjpk76pnMDZisSpljlpnDCklr/pkThZk7/okCcpnVyzEURZmphZmfr/WI+e +Z37eJqPKZ6reRfc2Z7umYTrGZ/yOZ/0WZ99+Z74mZ84aJ9SpJ9fyJ8AGqDE558EWqAGeqA2JKAK uqAM2qAJgaAQGqESOqEUWqGU4aAsZKEauqEc2qEe+qEgGqIiWkIYWqImeqKrOaIquqIs2qIuOoUo KkIvOqM0+iExeqM4mhY1uqM8Whs5mkE92m4/OqRE+hRBeqRImqRKuqQWVKRO+qRQqmxMGmJRykBT CmJVmqVamhFX+mFbikBd6mFfKkBhykVjGkBlukVnuqZs2qYJlKZwGqdyqoJuWqd2eqd46qRzuqd8 2qd++qerkaeCOqiEKi+AeqiImqiKGqeFLNqojvqokBqpkjqpU7SolnqpmFpBlFowmXpDm0ownZqg nyowobqCo3qqqxkQADs= ------=_NextPart_000_0006_01C7133B.5416B140-- From sip-bounces@ietf.org Tue Nov 28 16:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAX5-0004Sh-Dk; Tue, 28 Nov 2006 16:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAX3-0004Qn-U1 for sip@ietf.org; Tue, 28 Nov 2006 16:30:25 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpAX2-0004eA-B5 for sip@ietf.org; Tue, 28 Nov 2006 16:30:25 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASLUL900926; Tue, 28 Nov 2006 16:30:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN (Meeting Audio) Date: Tue, 28 Nov 2006 15:30:20 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2C977B@zrc2hxm0.corp.nortel.com> In-Reply-To: <456C98EA.2040801@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN (Meeting Audio) thread-index: AccTKrropr+jwgS4TpO/oh85eUiBKAACWbqg From: "Francois Audet" To: "Matt Lepinski" , "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Matt. That is very useful. PS: The name you didn't catch in there was John Peterson. In light of the transcript, are people OK with the current wording, as ammended by Paul Kyzivat? At least as a starting point point for=20 version -00 of the working group document? > -----Original Message----- > From: Matt Lepinski [mailto:mlepinski@bbn.com]=20 > Sent: Tuesday, November 28, 2006 12:16 > To: SIP WG > Subject: Re: [Sip] Re: SIPS and the PSTN (Meeting Audio) >=20 > There appeared to be some confusion regarding the proposed=20 > minutes (specifically discussion on the 4th Point of Dean's=20 > Trial Balloon) and the concensus on SIPS and the PSTN. > Therefore, I went back to the audio stream and collected the=20 > comments made regarding the points of Dean's proposal. >=20 > One point of note is that no one present at the meeting=20 > appeared to supported the idea that a SIPS call fail when it=20 > hits a PSTN gateway. >=20 > The audio recording can be obtained at: > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/iet > f67ch8-thu-noon.mp3 > tf67ch8-thu-noon.mp3>=20 >=20 >=20 > To aid anyone else who wants to listen to the audio stream,=20 > the number=20 > next to each comment is the time (relative to the start of the audio=20 > stream, represented as Hours:Minutes:Seconds) that the=20 > comment was made.=20 > (I apologize to the speakers whose names I didn't catch and of course=20 > for any transcription errors in the following.) >=20 > [2:41:00] Francois begins his explanation of the four points=20 > of Dean's=20 > Trail Balloon Proposal. >=20 > [2:44:40] Question from Jabber Channel: Does Point 2 mean all=20 > hops are TLS? > Answer: Yes >=20 > [2:45:30] Explanation of why the functionality provided by SIPS is=20 > important. [Not directly related to Point 4] >=20 > [2:47:45] Eric Burger says that we should remove Point 4. "Take the=20 > whole thing out [referring to Point 4] ... Unless it's really=20 > end-to-end=20 > it's like a non-solvable problem. 'It' being not just to a=20 > PSTN gateway,=20 > but to another IP gateway or whatever. If it is to a PSTN=20 > gateway that=20 > does terminate to a PSTN phone then actually the SIPS thing, the=20 > promise, was kept and if it's a gateway to another SIP thing=20 > then it is=20 > not kept ... Just don't mention PSTN termination" >=20 > [2:48:40] Question to Eric: "What about other protocols that=20 > you might=20 > gateway to?" > Eric's Answer: "It's a non-solvable problem."=20 > Therefore,=20 > delete bullet 4. >=20 > [2:48:50] Paul Kyzivat begins, "I've said all I want to say=20 > about 4, I'm=20 > not going to say anymore." He then argues against bullet 1 being a=20 > SHOULD. "I just don't believe that most of the time it's going to be=20 > done. And if it isn't going to be done most of the time then=20 > putting the=20 > SHOULD in is just holding out a false promise to people." >=20 > [2:49:45] Cullen Jennings comments on Points 1 and 4. On=20 > Point 1 he says=20 > "I think that we need to very clearly differentiate between=20 > what you to=20 > implement and what you need to use. As a general rule of=20 > thumb, on lots=20 > of our things here, we've tried to get people to implement=20 > security but=20 > not say that people necessarily have to use security." On Point 4 he=20 > says "I have a clear phrasing of what the commitment is,=20 > which is you're=20 > going to use TLS all the way to the UA. That's what I think it should=20 > be. Now my UA happens to be a speaker phone and I'm sitting=20 > in this room=20 > right now and there's a hundred people. I mean SIPS doesn't mean=20 > anything about what's going to happen on the other side of=20 > that speaker=20 > phone. I don't think it means anything about what's going to=20 > happen on=20 > the other side of that gateway. I don't think it means anything about=20 > what's going to happen on the other side of that protocol translator.=20 > Hopefully the protocol translater would do reasonable things,=20 > but it is=20 > impossible for us to specify beyond that point." >=20 > [2:51:00] Question for Cullen: "Would you say that it's a=20 > best current=20 > practice for an SBC to terminate a SIPS connection and generate a SIP=20 > connection on the other side?" >=20 > [2:51:15] Cullen replies: "I think that one of the most=20 > useful features=20 > that an SBC vender could offer today would be the one on the=20 > edge of an=20 > enterprise that could take unsecure phone calls from venders=20 > that hadn't=20 > managed to implement all of this stuff inside the enterprise=20 > and secure=20 > it as it crossed the internet. I think that's a great thing=20 > for people=20 > to go build. Needless to say the same thing needs to happen=20 > on incoming=20 > calls ... It doesn't matter what we say in these=20 > specifications though.=20 > Short of us breaking the PSTN there's no way to solve this=20 > ... We should=20 > not pretend that SIPS means anything beyond the UA." >=20 > [2:52:15] New speaker comments on Points=20 > 1 and 4. On=20 > Point 1 he observes that in IMS you end up using SIPS over an IPSEC=20 > connection. Therefore, you're encrypting the signalling=20 > twice, once with=20 > TLS and once with IPSEC. He raises the question: Is it good=20 > for us to=20 > do that? On Point 4, he says that we cannot go into the PSTN and we=20 > should not go beyond the IP side gaurantees that SIPS can provide. >=20 > [2:53:05] New speaker reminds everyone that it is Dean and=20 > not Francois=20 > that is to the source of this controversy. > "The one thing that I would say about 4 is for certain=20 > forms of protocol interworking where we're dealing with=20 > something that's=20 > going from IP to IP, basically from one IP based protocol to another=20 > one, I wouldn't see the harm in having something that was a BCP have=20 > like a SHOULD level thing saying if there is a comparable sort of =20 > mechanism in that protocol than you should try to invoke it=20 > ... I think=20 > you would certainly want to fail it if that capability was=20 > available in=20 > the other protocol but not invokable ... I wouldn't be=20 > opposed to there=20 > being some language like that. For something like PSTN which is so=20 > dissimilar to the way that SIP operates, I don't think it's=20 > reasonable=20 > to expect that any of this carries over ... So, no number 1,=20 > please and=20 > a softer 4." >=20 > [2:54:30] New speaker agrees with previous speaker. "That's=20 > exactly the=20 > same opinion that I had for PSTN and for similar networks." >=20 > [2:54:45] New speaker points out that Brian Rosen (who is not=20 > present)=20 > is adamant that SIPS calls should fail if they reach a PSTN gateway. >=20 > [2:54:55] Hadriel Kaplan agrees that Point 1 shouldn't be a=20 > SHOULD, "You=20 > can change it from a SHOULD to a MIGHT". He then comments on Point 4,=20 > "There's no question that SIPS is SIPS, it's part of SIP, not=20 > H.323, not=20 > PSTN, SS7, whatever. When you've reached the UAS, you've reached the=20 > UAS. You want to write a BCP, go right ahead, but the people=20 > who don't=20 > want to keep it SIPS or use SIPS or whatever will just ignore=20 > the BCP.=20 > For an SBC in particular ... As far as I know most of the=20 > SBC's that do=20 > support SIPS will obviously try to keep it SIPS on the other side of=20 > themselves. And, guess what, if the operator doesn't want them to, or=20 > says 'no you don't have to and you can use SIP', then they=20 > will do that=20 > because that's the whole concept of an SBC is that the=20 > operator decides=20 > ... I don't know the point of a BCP." He then goes on and argues that=20 > SIPS should not be deprecated. >=20 > [2:56:45] Dean Willis addresses Hadriel's point on the need=20 > for a BCP.=20 > His analogy is that a BCP on operational recommendations for SIPS is=20 > analogous to a BCP on operating email systems that says 'don't be an=20 > open email relay'. >=20 > [2:57:30] Hadriel says he understands but "It just seemed to me to be=20 > kind of funny, like writing a BCP that says 'Be Good'. The guys who=20 > don't won't to be good, won't be. There's no point in telling=20 > them to be=20 > good." >=20 > [2:57:45] Dean says "It's more on the order of 'if you don't=20 > lock your=20 > doors, people can wander in through your doors'." >=20 > [2:57:50] Hadriel says "Oh, you think that people might do it=20 > accidently=20 > ... You think they might just misconfigure ... I'm with you." >=20 > [2:58:30] Jon Elwell comments on Point 4 "I agree with the=20 > majority, I=20 > think, that it has to stop at the UAS, whether that's a SIP=20 > gateway or a=20 > phone or a speaker phone or whatever. I'm a little bit=20 > concerned about=20 > the B2BUA case, particularly what you mentioned Dean. If a B2BUA SBC=20 > upgrades a SIP request to SIPS then I guess no harm is done.=20 > The other=20 > way around though is a bit worse ... We don't normally legislate for=20 > B2BUA's, that's the problem, so I don't know how we deal with=20 > this, but=20 > I'm a little bit uneasy about it." >=20 > [2:59:20] Francois says, "I think the wording that Jon Peterson had=20 > actually applies here. It's a similar network. It's kind of two=20 > back-to-back SIP networks. It seems like a BCP-type thing." >=20 > [2:59:30] Keith says, "My assumption of the point of this=20 > conversation=20 > is that basically we now reflect the pros and cons in the document." >=20 > [2:59:45] Francois indicates that he has a sense from the=20 > room of what=20 > we heard. "[Point] 1 I think is some level of support but not=20 > that much.=20 > [Point] 4 I think we have a pretty good concesus except for=20 > one person=20 > who's not here. [Point] 3 is obvious, and [Point] 2 I think is ...=20 > implicitly I think that people like the idea of deprecating=20 > the last hop=20 > but we didn't really have a vote or anything on that." >=20 > [3:00:20] Dean says "I think we have concensus on pretty much=20 > everything=20 > except for the fine-print writing of 4, and I think there's a fairly=20 > strong sense that number 1 is out of place and it just echos what's=20 > already in 3261. So I think we can reduce number 4 to a=20 > should level and=20 > explain the issues and do away with number 1 and I think everyone=20 > besides Brian Rosen will be happy." >=20 >=20 > Cullen Jennings wrote: >=20 > > > > On Nov 27, 2006, at 1:42 PM, Paul Kyzivat wrote: >=20 > >=20 > >> The above seems to be a rehash of the prior on-list=20 > arguments made =20 > >> in support of this conclusion. > >> > >> IMO if the request has reached a UAS that is properly=20 > authenticated =20 > >> as the intended recipient of the request, then the=20 > contract implied =20 > >> by SIPS has been fulfilled, and what happens after that is out of =20 > >> scope. Whether that UAS happens to be a gateway is irrelevant as =20 > >> long as it has the proper credentials for the target address. > >> > >> Paul > > > > > > I don't remember what the consensus was but I'm seem to=20 > recall making =20 > > a similar argument to Paul. Perhaps someone could listen to=20 > the audio =20 > > recordings of this and try and straight it out. I would be very =20 > > surprised if we had consensus that if one side of a IP to=20 > IP gateway =20 > > (such as protocol translator) was doing sips that the other=20 > side also =20 > > had to do sips. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 16:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAjd-0007ze-Ov; Tue, 28 Nov 2006 16:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpAjc-0007zS-0j for sip@ietf.org; Tue, 28 Nov 2006 16:43:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpAja-0006Yv-EN for sip@ietf.org; Tue, 28 Nov 2006 16:43:23 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 28 Nov 2006 13:43:21 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kASLhKiV026342; Tue, 28 Nov 2006 16:43:20 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kASLhGDo009871; Tue, 28 Nov 2006 16:43:20 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:43:06 -0500 Received: from [161.44.55.116] ([161.44.55.116]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:43:05 -0500 Message-ID: <456CAD68.4030701@cisco.com> Date: Tue, 28 Nov 2006 16:43:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Re: SIPS and the PSTN References: <1ECE0EB50388174790F9694F77522CCF0E2C925A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C925A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 21:43:05.0627 (UTC) FILETIME=[2FE866B0:01C71336] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3557; t=1164750200; x=1165614200; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20 |To:=20Francois=20Audet=20; bh=JuCpbNr5tNVJSSWKxokPktILmzniT5IGgsW7D05cbrA=; b=kxJKTVKd0VrXpL54OukJIt0T4VfH/xX0x07Blm1l3G22blQF+eYXOtFwzVp9L+gbXVS2IhZ+ 8V3kjGSbLkVptSyzJ/4vj/g/bUC++OCIr7WhfunIxxOPYn7A8bPrkuxE; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Joel M. Halpern" , SIP WG , Paul Kyzivat , Michael Procter , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I must say I'm a bit worried about 'should'. I think Dean raised this point; since tons of "proxies" todays are also b2bua's in some sense (that is, they do things a pure proxy cannot), this may very well reduce the overall effectiveness of sips to just SHOULD use TLS. That seems ever looser than what we have today. I'd rather not try to define what constitutes a b2bua that can downgrade sips, and what kind of b2bua cannot. Instead, it seems easier to simply state that if you are not the target of the sips URI, and you have a SIP next-hop, you MUST use TLS on that hop. -Jonathan R. Francois Audet wrote: > Agreed, that's why it's a should, and that's why that section is > short... > > Are we OK with the wording? > > And remember: concrete proposals... > > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, November 28, 2006 08:42 >>To: Audet, Francois (SC100:3055) >>Cc: Dean Willis; Joel M. Halpern; SIP WG >>Subject: Re: [Sip] Re: SIPS and the PSTN >> >>I think I am ok with SHOULD for B2BUAs, but I still think it >>is hard to be specific because of the wide variety of things >>that B2BUAs can do. >> >>Consider a different kind of B2BUA - a conference focus. If >>it allows connections via SIPS, should it require all >>connections to be SIPS? >>While that might be a policy for some conferences, I don't >>think it is the only reasonable policy. >> >> Paul >> >>Francois Audet wrote: >> >>>Let's try to write up something for the document. >>>I am pretty sure that I remember that in essence, what we >> >>decided was >> >>>that: >>>1) Anything outside SIP network is out-of-scope >>>2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that >>>there ain't nothing we >>> can do to enforce it of course). >>> >>>Here is a strawman: >>> >>> 3.1. Scope of SIPS >>> >>> It is outside of the scope of this document to specify >> >>what happens >> >>> when a SIPS URI defines a UAS that "maps" outside of the >> >>SIP network. >> >>> For example, to other networks such as the PSTN or an >> >>H.323 network. >> >>> These networks have their own standards on what is appropriate >>> security levels. >>> >>> Derived connections in SIP however should use SIPS >> >>end-to-end, even >> >>> accross distinct SIP networks. For example, If a >> >>Back-to-Back-User- >> >>> Agent (B2BUA) receives a request destined to a SIPS >> >>Request-URI and >> >>> it forwards it, it should use a SIPS Request-URI on the outgoing >>> connection as well. This could happen for example when >> >>the B2BUA is >> >>> Session Border Controller sitting between two SIP >> >>networks. It could >> >>> also happen in an Application Server or with SIP third-party call >>> control [RFC3725]. >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 17:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpB9B-0007Tn-3c; Tue, 28 Nov 2006 17:09:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpB99-0007Ta-Fo for sip@ietf.org; Tue, 28 Nov 2006 17:09:47 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpB97-00024i-1T for sip@ietf.org; Tue, 28 Nov 2006 17:09:47 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASM9Z125430; Tue, 28 Nov 2006 17:09:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 16:09:33 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2C9854@zrc2hxm0.corp.nortel.com> In-Reply-To: <456CAD68.4030701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccTNj38voVwF9QMRXKXzZRbGjAANAAAeb7w From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: "Joel M. Halpern" , SIP WG , Paul Kyzivat , Michael Procter , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What about this: 3.1. Scope of SIPS It is outside of the scope of this document to specify what happens when a SIPS URI identifies a UAS that "maps" outside of the SIP network. For example, to other networks such as the PSTN or an H.323 network. These networks have their own standards on what is appropriate security level =20 If a B2BUA is used in lieu of a proxy (as is common in practical deployment),=20 if it receives a request destined to a SIPS Request-URI that does not identify itself=20 and it forwards it on towards that Request-URI, it must use a=20 SIPS Request-URI on the outgoing connection as well. =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, November 28, 2006 13:43 > To: Audet, Francois (SC100:3055) > Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG;=20 > Dean Willis > Subject: Re: [Sip] Re: SIPS and the PSTN >=20 > I must say I'm a bit worried about 'should'. I think Dean=20 > raised this point; since tons of "proxies" todays are also=20 > b2bua's in some sense (that is, they do things a pure proxy=20 > cannot), this may very well reduce the overall effectiveness=20 > of sips to just SHOULD use TLS. That seems ever looser than=20 > what we have today. >=20 > I'd rather not try to define what constitutes a b2bua that=20 > can downgrade sips, and what kind of b2bua cannot. Instead,=20 > it seems easier to simply state that if you are not the=20 > target of the sips URI, and you have a SIP next-hop, you MUST=20 > use TLS on that hop. >=20 > -Jonathan R. >=20 > Francois Audet wrote: >=20 > > Agreed, that's why it's a should, and that's why that section is=20 > > short... > >=20 > > Are we OK with the wording? > >=20 > > And remember: concrete proposals... > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Tuesday, November 28, 2006 08:42 > >>To: Audet, Francois (SC100:3055) > >>Cc: Dean Willis; Joel M. Halpern; SIP WG > >>Subject: Re: [Sip] Re: SIPS and the PSTN > >> > >>I think I am ok with SHOULD for B2BUAs, but I still think=20 > it is hard=20 > >>to be specific because of the wide variety of things that=20 > B2BUAs can=20 > >>do. > >> > >>Consider a different kind of B2BUA - a conference focus. If=20 > it allows=20 > >>connections via SIPS, should it require all connections to be SIPS? > >>While that might be a policy for some conferences, I don't=20 > think it is=20 > >>the only reasonable policy. > >> > >> Paul > >> > >>Francois Audet wrote: > >> > >>>Let's try to write up something for the document. > >>>I am pretty sure that I remember that in essence, what we > >> > >>decided was > >> > >>>that: > >>>1) Anything outside SIP network is out-of-scope > >>>2) B2BUA SHOULD preserve SIPS on both sides. (It was also=20 > said that=20 > >>>there ain't nothing we > >>> can do to enforce it of course). > >>> > >>>Here is a strawman: > >>> > >>> 3.1. Scope of SIPS > >>> > >>> It is outside of the scope of this document to specify > >> > >>what happens > >> > >>> when a SIPS URI defines a UAS that "maps" outside of the > >> > >>SIP network. > >> > >>> For example, to other networks such as the PSTN or an > >> > >>H.323 network. > >> > >>> These networks have their own standards on what is appropriate > >>> security levels. > >>> > >>> Derived connections in SIP however should use SIPS > >> > >>end-to-end, even > >> > >>> accross distinct SIP networks. For example, If a > >> > >>Back-to-Back-User- > >> > >>> Agent (B2BUA) receives a request destined to a SIPS > >> > >>Request-URI and > >> > >>> it forwards it, it should use a SIPS Request-URI on the outgoing > >>> connection as well. This could happen for example when > >> > >>the B2BUA is > >> > >>> Session Border Controller sitting between two SIP > >> > >>networks. It could > >> > >>> also happen in an Application Server or with SIP=20 > third-party call > >>> control [RFC3725]. > >>> > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 17:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBTU-0005r4-9o; Tue, 28 Nov 2006 17:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBTS-0005kb-MP for sip@ietf.org; Tue, 28 Nov 2006 17:30:46 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBTQ-00057M-1V for sip@ietf.org; Tue, 28 Nov 2006 17:30:46 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 28 Nov 2006 14:30:43 -0800 X-IronPort-AV: i="4.09,471,1157353200"; d="scan'208"; a="755718386:sNHT53584932" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kASMUhjv024822; Tue, 28 Nov 2006 14:30:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kASMURdM025438; Tue, 28 Nov 2006 14:30:43 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 17:30:32 -0500 Received: from [161.44.55.116] ([161.44.55.116]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 17:30:32 -0500 Message-ID: <456CB887.3020504@cisco.com> Date: Tue, 28 Nov 2006 17:30:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Re: SIPS and the PSTN References: <1ECE0EB50388174790F9694F77522CCF0E2C9854@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C9854@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 22:30:32.0080 (UTC) FILETIME=[D086A900:01C7133C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5336; t=1164753043; x=1165617043; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20; bh=er23WABgbiVdlTXY2rprYr0IfiSd9Lpje13AB8bLJu0=; b=tNsNfEvWI1FLuX8G0z6Ckjfpc0c+bqkUV2muCqo/tWKX8bkyC8+GSIgspRufDPbpWuaFR1pn iU1wy2fvodN/tgvEOCBbPW7lCCWQeAhlr7r4GKBDbhNK/LQ6GIxi8jyN; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: "Joel M. Halpern" , SIP WG , Paul Kyzivat , Michael Procter , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Making the must capital in the second paragraph, sounds good to me. -Jonathan R. Francois Audet wrote: > What about this: > > > 3.1. Scope of SIPS > > It is outside of the scope of this document to specify what happens > when a SIPS URI identifies a UAS that "maps" outside of the SIP > network. For example, to other networks such as the PSTN or an H.323 > network. These networks have their own standards on what is > appropriate security level > > If a B2BUA is used in lieu of a proxy (as is common in practical > deployment), > if it receives a request destined to a SIPS Request-URI that does not > identify itself > and it forwards it on towards that Request-URI, it must use a > SIPS Request-URI on the outgoing connection as well. > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Tuesday, November 28, 2006 13:43 >>To: Audet, Francois (SC100:3055) >>Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; >>Dean Willis >>Subject: Re: [Sip] Re: SIPS and the PSTN >> >>I must say I'm a bit worried about 'should'. I think Dean >>raised this point; since tons of "proxies" todays are also >>b2bua's in some sense (that is, they do things a pure proxy >>cannot), this may very well reduce the overall effectiveness >>of sips to just SHOULD use TLS. That seems ever looser than >>what we have today. >> >>I'd rather not try to define what constitutes a b2bua that >>can downgrade sips, and what kind of b2bua cannot. Instead, >>it seems easier to simply state that if you are not the >>target of the sips URI, and you have a SIP next-hop, you MUST >>use TLS on that hop. >> >>-Jonathan R. >> >>Francois Audet wrote: >> >> >>>Agreed, that's why it's a should, and that's why that section is >>>short... >>> >>>Are we OK with the wording? >>> >>>And remember: concrete proposals... >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: Tuesday, November 28, 2006 08:42 >>>>To: Audet, Francois (SC100:3055) >>>>Cc: Dean Willis; Joel M. Halpern; SIP WG >>>>Subject: Re: [Sip] Re: SIPS and the PSTN >>>> >>>>I think I am ok with SHOULD for B2BUAs, but I still think >> >>it is hard >> >>>>to be specific because of the wide variety of things that >> >>B2BUAs can >> >>>>do. >>>> >>>>Consider a different kind of B2BUA - a conference focus. If >> >>it allows >> >>>>connections via SIPS, should it require all connections to be SIPS? >>>>While that might be a policy for some conferences, I don't >> >>think it is >> >>>>the only reasonable policy. >>>> >>>> Paul >>>> >>>>Francois Audet wrote: >>>> >>>> >>>>>Let's try to write up something for the document. >>>>>I am pretty sure that I remember that in essence, what we >>>> >>>>decided was >>>> >>>> >>>>>that: >>>>>1) Anything outside SIP network is out-of-scope >>>>>2) B2BUA SHOULD preserve SIPS on both sides. (It was also >> >>said that >> >>>>>there ain't nothing we >>>>> can do to enforce it of course). >>>>> >>>>>Here is a strawman: >>>>> >>>>> 3.1. Scope of SIPS >>>>> >>>>> It is outside of the scope of this document to specify >>>> >>>>what happens >>>> >>>> >>>>> when a SIPS URI defines a UAS that "maps" outside of the >>>> >>>>SIP network. >>>> >>>> >>>>> For example, to other networks such as the PSTN or an >>>> >>>>H.323 network. >>>> >>>> >>>>> These networks have their own standards on what is appropriate >>>>> security levels. >>>>> >>>>> Derived connections in SIP however should use SIPS >>>> >>>>end-to-end, even >>>> >>>> >>>>> accross distinct SIP networks. For example, If a >>>> >>>>Back-to-Back-User- >>>> >>>> >>>>> Agent (B2BUA) receives a request destined to a SIPS >>>> >>>>Request-URI and >>>> >>>> >>>>> it forwards it, it should use a SIPS Request-URI on the outgoing >>>>> connection as well. This could happen for example when >>>> >>>>the B2BUA is >>>> >>>> >>>>> Session Border Controller sitting between two SIP >>>> >>>>networks. It could >>>> >>>> >>>>> also happen in an Application Server or with SIP >> >>third-party call >> >>>>> control [RFC3725]. >>>>> >>>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol Use >>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>sipping@ietf.org for new developments on the application of sip >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 18:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpCIN-0008Ua-LE; Tue, 28 Nov 2006 18:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpCIM-0008UN-6k for sip@ietf.org; Tue, 28 Nov 2006 18:23:22 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpCIJ-0004VU-Ol for sip@ietf.org; Tue, 28 Nov 2006 18:23:22 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kASNG3k07473; Tue, 28 Nov 2006 18:16:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 17:23:08 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E2C9986@zrc2hxm0.corp.nortel.com> In-Reply-To: <456CB887.3020504@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccTPNuiHcDprT12TGqkqbICsqtdOQABwKjw From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: SIP WG , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, except that I've been instructed by the Chairs that this document is 'informational' only. I assume that it means that I can't make normative statements of any kind. Is this true? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, November 28, 2006 14:31 > To: Audet, Francois (SC100:3055) > Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG;=20 > Dean Willis > Subject: Re: [Sip] Re: SIPS and the PSTN >=20 > Making the must capital in the second paragraph, sounds good to me. >=20 > -Jonathan R. >=20 > Francois Audet wrote: >=20 > > What about this: > >=20 > >=20 > > 3.1. Scope of SIPS > >=20 > > It is outside of the scope of this document to specify=20 > what happens > > when a SIPS URI identifies a UAS that "maps" outside of the SIP > > network. For example, to other networks such as the=20 > PSTN or an H.323 > > network. These networks have their own standards on what is > > appropriate security level > > =20 > > If a B2BUA is used in lieu of a proxy (as is common in practical=20 > > deployment), > > if it receives a request destined to a SIPS Request-URI=20 > that does=20 > > not identify itself > > and it forwards it on towards that Request-URI, it must use a=20 > > SIPS Request-URI on the outgoing connection as well. =20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>Sent: Tuesday, November 28, 2006 13:43 > >>To: Audet, Francois (SC100:3055) > >>Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean=20 > >>Willis > >>Subject: Re: [Sip] Re: SIPS and the PSTN > >> > >>I must say I'm a bit worried about 'should'. I think Dean=20 > raised this=20 > >>point; since tons of "proxies" todays are also b2bua's in=20 > some sense=20 > >>(that is, they do things a pure proxy cannot), this may very well=20 > >>reduce the overall effectiveness of sips to just SHOULD use=20 > TLS. That=20 > >>seems ever looser than what we have today. > >> > >>I'd rather not try to define what constitutes a b2bua that can=20 > >>downgrade sips, and what kind of b2bua cannot. Instead, it seems=20 > >>easier to simply state that if you are not the target of=20 > the sips URI,=20 > >>and you have a SIP next-hop, you MUST use TLS on that hop. > >> > >>-Jonathan R. > >> > >>Francois Audet wrote: > >> > >> > >>>Agreed, that's why it's a should, and that's why that section is=20 > >>>short... > >>> > >>>Are we OK with the wording? > >>> > >>>And remember: concrete proposals... > >>>=20 > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>Sent: Tuesday, November 28, 2006 08:42 > >>>>To: Audet, Francois (SC100:3055) > >>>>Cc: Dean Willis; Joel M. Halpern; SIP WG > >>>>Subject: Re: [Sip] Re: SIPS and the PSTN > >>>> > >>>>I think I am ok with SHOULD for B2BUAs, but I still think > >> > >>it is hard > >> > >>>>to be specific because of the wide variety of things that > >> > >>B2BUAs can > >> > >>>>do. > >>>> > >>>>Consider a different kind of B2BUA - a conference focus. If > >> > >>it allows > >> > >>>>connections via SIPS, should it require all connections=20 > to be SIPS? > >>>>While that might be a policy for some conferences, I don't > >> > >>think it is > >> > >>>>the only reasonable policy. > >>>> > >>>> Paul > >>>> > >>>>Francois Audet wrote: > >>>> > >>>> > >>>>>Let's try to write up something for the document. > >>>>>I am pretty sure that I remember that in essence, what we > >>>> > >>>>decided was > >>>> > >>>> > >>>>>that: > >>>>>1) Anything outside SIP network is out-of-scope > >>>>>2) B2BUA SHOULD preserve SIPS on both sides. (It was also > >> > >>said that > >> > >>>>>there ain't nothing we > >>>>> can do to enforce it of course). > >>>>> > >>>>>Here is a strawman: > >>>>> > >>>>> 3.1. Scope of SIPS > >>>>> > >>>>> It is outside of the scope of this document to specify > >>>> > >>>>what happens > >>>> > >>>> > >>>>> when a SIPS URI defines a UAS that "maps" outside of the > >>>> > >>>>SIP network. > >>>> > >>>> > >>>>> For example, to other networks such as the PSTN or an > >>>> > >>>>H.323 network. > >>>> > >>>> > >>>>> These networks have their own standards on what is=20 > appropriate =20 > >>>>> security levels. > >>>>> > >>>>> Derived connections in SIP however should use SIPS > >>>> > >>>>end-to-end, even > >>>> > >>>> > >>>>> accross distinct SIP networks. For example, If a > >>>> > >>>>Back-to-Back-User- > >>>> > >>>> > >>>>> Agent (B2BUA) receives a request destined to a SIPS > >>>> > >>>>Request-URI and > >>>> > >>>> > >>>>> it forwards it, it should use a SIPS Request-URI on=20 > the outgoing =20 > >>>>> connection as well. This could happen for example when > >>>> > >>>>the B2BUA is > >>>> > >>>> > >>>>> Session Border Controller sitting between two SIP > >>>> > >>>>networks. It could > >>>> > >>>> > >>>>> also happen in an Application Server or with SIP > >> > >>third-party call > >> > >>>>> control [RFC3725]. > >>>>> > >>>> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol Use=20 > >>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>sipping@ietf.org for new developments on the application of sip > >>> > >> > >>--=20 > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Cisco Fellow Parsippany, NJ=20 > >>07054-2711 > >>Cisco Systems > >>jdrosen@cisco.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.cisco.com > >> > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Nov 28 18:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpCdQ-0006ld-7o; Tue, 28 Nov 2006 18:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpCdO-0006XM-4B for sip@ietf.org; Tue, 28 Nov 2006 18:45:06 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpCdM-000725-QR for sip@ietf.org; Tue, 28 Nov 2006 18:45:06 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kASNbtk08615; Tue, 28 Nov 2006 18:37:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Tue, 28 Nov 2006 17:44:59 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FE4A7E2@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C9986@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTPNuiHcDprT12TGqkqbICsqtdOQABwKjwAADLZ7A= From: "Samir Srivastava" To: "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP WG , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org IMHO, after SIPS we are committing one more mistake. After knowing SIPS is completely broken, we are attempting to justify the need on the charter. I am failing to see the value of any these documents. Rather go to IESG directly and get this milestone removed from the charter. All this is merely wastage of cycles. BTW, I don't want to open the complete ranting mode now. Thx Samir > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, November 28, 2006 3:23 PM > To: Jonathan Rosenberg > Cc: SIP WG; Drage, Keith (Keith); Dean Willis > Subject: RE: [Sip] Re: SIPS and the PSTN >=20 > Yeah, except that I've been instructed by the Chairs that this document > is 'informational' only. >=20 > I assume that it means that I can't make normative statements of any > kind. Is this true? >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 02:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJnI-0007JO-Ts; Wed, 29 Nov 2006 02:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJnG-0007CP-PO for sip@ietf.org; Wed, 29 Nov 2006 02:23:46 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpJnF-00055X-Bb for sip@ietf.org; Wed, 29 Nov 2006 02:23:46 -0500 Received: (qmail 27578 invoked by uid 0); 29 Nov 2006 07:24:51 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Nov 2006 07:24:51 -0000 Message-ID: <000801c71387$489d2780$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Samir Srivastava" , "Francois Audet" , "Jonathan Rosenberg" References: <62B9B0847CC47543B6B3B5E26BD268E60FE4A7E2@zrc2hxm2.corp.nortel.com> Subject: Re: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 08:23:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: SIP WG , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I see the value of a document clarifying RFC3261 and documenting best practices around SIPS. However, I also think there are limits to what a draft can hope to achieve. Saying that a B2BUA MUST do this and that will not magically change the way the world is evolving. A B2BUA that forwards SIPS to SIP can still interoperate, it may be breaking the implicit assumptions / expectations that (some of) the standards people have/had in mind while specifying the SIP protocol, but to the average consumer that won't make much difference. So in short: write down what may happen when using SIPS, recommend what should ideally happen, and move on. Regards, Jeroen Samir Srivastava wrote: > IMHO, after SIPS we are committing one more mistake. After knowing > SIPS is completely broken, we are attempting to justify the need on > the charter. I am failing to see the value of any these documents. > Rather go to IESG directly and get this milestone removed from the > charter. All this is merely wastage of cycles. BTW, I don't want to > open the complete ranting mode now. > > Thx > Samir > >> -----Original Message----- >> From: Audet, Francois (SC100:3055) >> Sent: Tuesday, November 28, 2006 3:23 PM >> To: Jonathan Rosenberg >> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >> Subject: RE: [Sip] Re: SIPS and the PSTN >> >> Yeah, except that I've been instructed by the Chairs that this >> document is 'informational' only. >> >> I assume that it means that I can't make normative statements of any >> kind. Is this true? >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 qbjopvlpl@pldt.net Wed Nov 29 03:28:26 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKnq-0008Ou-Tt for sip-archive@lists.ietf.org; Wed, 29 Nov 2006 03:28:26 -0500 Received: from [58.69.14.168] (helo=58.69.14.168.pldt.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpKnn-00014w-2Q for sip-archive@lists.ietf.org; Wed, 29 Nov 2006 03:28:26 -0500 From: "opinions overview" To: sip-archive@lists.ietf.org Subject: Wall Street Alert! Date: Wed, 29 Nov 2006 16:37:30 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C713D4.A9CC6E10" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccT1KnOiiqEUASrTsO5lpIBlXaL0g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <942BA5F071FFDAE.612B49D81A@pldt.net> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0002_01C713D4.A9CC6E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Company: Bralorne Mining Company (BLNM.OB) is China Telcom & China Netcom's
Primary VOIP Network Agent.
Huge VOIP Contract Signed With Beijing Oriental Inc.

BLNM.OB Price Climbs 81% and Volume is up 10000% In Just Three Days Trading! It's not to late to get in!

BLNM, via Beijing QTC, lands another huge contract with Beijing Oriental Inc. Beijing Oriental Inc. is China's leading exhibition and conference holding company. Beijing QTC (BLNM) agrees to provide Beijing Oriental with its 3GenisIP Integrated Access System. This provides them with local, and long distance calling, international numbers and a broadband connection in a single solution.

BLNM.OB is now Authorized in many cities and provinces in China by the two giant telecoms, China Netcom and China Telecom, as the primary authorized VoIP network agent.

This company keeps expanding. They are landing one deal after another. And they are fast become one of the big players in the worlds fastest growing telcom market. This news will make BLNM make huge jumps in the market tomorrow. BLNM has already climbed 82% since last week when these series of news releases began.

Stay ahead of the growth, get on board with BLNM Wed morning, first thing.
------=_NextPart_000_0002_01C713D4.A9CC6E10-- From sip-bounces@ietf.org Wed Nov 29 04:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLIw-0005cn-Nj; Wed, 29 Nov 2006 04:00:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLIv-0005ad-8a for sip@ietf.org; Wed, 29 Nov 2006 04:00:33 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpLIt-0005AU-Om for sip@ietf.org; Wed, 29 Nov 2006 04:00:33 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAT90EZx004276; Wed, 29 Nov 2006 11:00:19 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 10:59:52 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 10:59:52 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Wed, 29 Nov 2006 10:59:48 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F030E72FD@esebe103.NOE.Nokia.com> In-Reply-To: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccMvdVv5uMs1mHcRQaWY453swM2ugG0du2Q From: To: X-OriginalArrivalTime: 29 Nov 2006 08:59:52.0117 (UTC) FILETIME=[BB430E50:01C71394] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061129110021-10223BB0-62804387/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >about STUN keepalive usage and discovery, since double CRLF is fully=20 >backwards compatible with even RFC 2543 implementations. I am=20 >bringing this up on the list because I hope the WG can look back on=20 >this and not make the mistake of snowballing complexity to preserve=20 >UDP parity again in the future. Rohan is making a valid point here and I believe in Outbound there is still room for change to cater for CRLF keepalives as an option to STUN keepalives over TCP. I am calling the WG to look back on the keepalive decision made earlier for TCP and proposing that Outbound should also cover=20 CRLF keepalive option. Reasons for this proposal: >The problem I see is that we have two separate communities using the=20 >outbound draft: > >1) folks that want to get through NATs and Firewalls in the public=20 >Internet at large - they want to use TCP and TLS with double CRLF for=20 >keepalives. One "flow" is always one connection. The milestone for=20 >this would read "Make TCP and TLS work in the Internet". I agree with the intents of this community. However this is not what the current Outbound provides. Outbound specifies two options for keepalives for reliable connections: TCP keepalive and STUN. These options were agreed in IETF 65, a cite from the minutes: =20 Proposal:=20 Do STUN for TCP and UDP=20 Do CRLF for TCP and STUN for UDP=20 TCP KeepAlive if supported, 1 or 2 otherwise=20 Resolutions: =20 OS TCP KeepAlive should be used if the client supports it.=20 Need something more because OS TCP KeepAlive is not supported in every client OS.=20 Consensus to use STUN for UDP=20 Consensus to use STUN for TCP, with use of OS TCP keep alive above. =20 In that meeting the basic assumption was that every Outbound compliant client should implement both UDP and TCP even if that is not explicitely mentioned in the draft. However latest -06 version now makes that debatable by stating: Use of outbound with UDP flows typically prevents messages larger than 1300 bytes from being delivered using TCP as described in Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP flows in environments where requests are expected to be larger than this size is therefore NOT RECOMMENDED. In practice this seems to justify implementing "TCP only" UAs what comes to the Outbound support. In that case the basic assumption with STUN keepalive (implement it for TCP as it is anyway needed for UDP as well) would become obsolete. For implementations which can not use TCP keepalive, CRLF would obviously provide a great benefit without significant increase of complexity to Outbound. P.S. Last week I made a proposal for "stripped Outbound" without UDP, STUN keepalives and multiple registrations. As that proposal did not receive any comments, I decided to propose this minimal addition to Outbound as an alternative that might be a bit easier to accept but still achieve some of the benefits. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 06:19:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpNRO-00055r-8o; Wed, 29 Nov 2006 06:17:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpNRM-000530-Ja for sip@ietf.org; Wed, 29 Nov 2006 06:17:24 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpNRL-0006XB-8i for sip@ietf.org; Wed, 29 Nov 2006 06:17:24 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATBHJ624408; Wed, 29 Nov 2006 06:17:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 05:17:18 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FEB3D18@zrc2hxm2.corp.nortel.com> In-Reply-To: <000801c71387$489d2780$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTh1Eq1k9qKfJBS4CxFevYrxGoPgAIFuLQ From: "Samir Srivastava" To: "Jeroen van Bemmel" , "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: SIP WG , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What is the utility of SIPS ? I have posted so many times the limitation of SIPS. Tell me what part you like. Double entries. Upgrade / dowgrade etc. retargeting. What will you do for telURI. It's a king with underwar only as Paul said in the frustration earlier. Thx Samir=20 >-----Original Message----- >From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: Tuesday, November 28, 2006 11:24 PM >To: Srivastava, Samir (SC100:8826); Audet, Francois=20 >(SC100:3055); Jonathan Rosenberg >Cc: SIP WG; Drage, Keith (Keith); Dean Willis >Subject: Re: [Sip] Re: SIPS and the PSTN > >I see the value of a document clarifying RFC3261 and=20 >documenting best practices around SIPS. However, I also think=20 >there are limits to what a draft can hope to achieve. Saying=20 >that a B2BUA MUST do this and that will not magically change=20 >the way the world is evolving. A B2BUA that forwards SIPS to=20 >SIP can still interoperate, it may be breaking the implicit=20 >assumptions / expectations that (some of) the standards people=20 >have/had in mind while specifying the SIP protocol, but to the=20 >average consumer that won't make much difference. So in short:=20 >write down what may happen when using SIPS, recommend what=20 >should ideally happen, and move on. > >Regards, >Jeroen > >Samir Srivastava wrote: >> IMHO, after SIPS we are committing one more mistake. After knowing=20 >> SIPS is completely broken, we are attempting to justify the need on=20 >> the charter. I am failing to see the value of any these documents. >> Rather go to IESG directly and get this milestone removed from the=20 >> charter. All this is merely wastage of cycles. BTW, I don't want to=20 >> open the complete ranting mode now. >> >> Thx >> Samir >> >>> -----Original Message----- >>> From: Audet, Francois (SC100:3055) >>> Sent: Tuesday, November 28, 2006 3:23 PM >>> To: Jonathan Rosenberg >>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >>> Subject: RE: [Sip] Re: SIPS and the PSTN >>> >>> Yeah, except that I've been instructed by the Chairs that this=20 >>> document is 'informational' only. >>> >>> I assume that it means that I can't make normative=20 >statements of any=20 >>> kind. Is this true? >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 06:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpNZ3-00059o-Mx; Wed, 29 Nov 2006 06:25:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpNZ2-00059i-Oo for sip@ietf.org; Wed, 29 Nov 2006 06:25:20 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpNZ0-00086X-Vo for sip@ietf.org; Wed, 29 Nov 2006 06:25:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATBPF200577; Wed, 29 Nov 2006 06:25:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 05:25:14 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FEB3D19@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FEB3D18@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTh1Eq1k9qKfJBS4CxFevYrxGoPgAIFuLQAAAr5WA= From: "Samir Srivastava" To: "Samir Srivastava" , "Jeroen van Bemmel" , "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: SIP WG , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Added to this, we have S/MIME mentioned at so many places. But nobody is using it. I think similar will be for SIPS. Also as per the process, refer CMM/SEI KPA's there is constant process improvement. If IETF current process doesn't allow to remove the milestone, then update the process. It's causing more of a pain. Who will be using SIPS ? Should we voting on the mailing list for the need of the this document ? I am frustrated the way this group behaves. It wanted to get rid of RUNNING CODE well established truth, but for this idiotic document, you don't want to agree. It has been two meetings. Ideally it should have been gone in the Montreal itself, if people allowed me to speak. At that time where was your purist mindset, which you were arguing for the PING. Thx Samir=20 >-----Original Message----- >From: Srivastava, Samir (SC100:8826)=20 >Sent: Wednesday, November 29, 2006 3:17 AM >To: Jeroen van Bemmel; Audet, Francois (SC100:3055); Jonathan Rosenberg >Cc: SIP WG; Drage, Keith (Keith); Dean Willis >Subject: RE: [Sip] Re: SIPS and the PSTN > >What is the utility of SIPS ? I have posted so many times the=20 >limitation of SIPS. >Tell me what part you like. Double entries. Upgrade / dowgrade etc. >retargeting. What will you do for telURI. It's a king with=20 >underwar only as Paul said in the frustration earlier. > >Thx >Samir=20 > >>-----Original Message----- >>From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>Sent: Tuesday, November 28, 2006 11:24 PM >>To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055);=20 >>Jonathan Rosenberg >>Cc: SIP WG; Drage, Keith (Keith); Dean Willis >>Subject: Re: [Sip] Re: SIPS and the PSTN >> >>I see the value of a document clarifying RFC3261 and documenting best=20 >>practices around SIPS. However, I also think there are limits=20 >to what a=20 >>draft can hope to achieve. Saying that a B2BUA MUST do this and that=20 >>will not magically change the way the world is evolving. A B2BUA that=20 >>forwards SIPS to SIP can still interoperate, it may be breaking the=20 >>implicit assumptions / expectations that (some of) the=20 >standards people=20 >>have/had in mind while specifying the SIP protocol, but to=20 >the average=20 >>consumer that won't make much difference. So in short: >>write down what may happen when using SIPS, recommend what should=20 >>ideally happen, and move on. >> >>Regards, >>Jeroen >> >>Samir Srivastava wrote: >>> IMHO, after SIPS we are committing one more mistake. After knowing=20 >>> SIPS is completely broken, we are attempting to justify the need on=20 >>> the charter. I am failing to see the value of any these documents. >>> Rather go to IESG directly and get this milestone removed from the=20 >>> charter. All this is merely wastage of cycles. BTW, I don't want to=20 >>> open the complete ranting mode now. >>> >>> Thx >>> Samir >>> >>>> -----Original Message----- >>>> From: Audet, Francois (SC100:3055) >>>> Sent: Tuesday, November 28, 2006 3:23 PM >>>> To: Jonathan Rosenberg >>>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >>>> Subject: RE: [Sip] Re: SIPS and the PSTN >>>> >>>> Yeah, except that I've been instructed by the Chairs that this=20 >>>> document is 'informational' only. >>>> >>>> I assume that it means that I can't make normative >>statements of any >>>> kind. Is this true? >>>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use=20 >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>> sipping@ietf.org for new developments on the application of sip >> >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 06:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpNsW-0002Ti-Du; Wed, 29 Nov 2006 06:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpNsV-0002Tc-5r for sip@ietf.org; Wed, 29 Nov 2006 06:45:27 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpNsO-0003Cm-Q7 for sip@ietf.org; Wed, 29 Nov 2006 06:45:27 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kATBj7ph007494; Wed, 29 Nov 2006 05:45:11 -0600 (CST) Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 05:45:07 -0600 Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 05:45:06 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 12:45:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 12:45:02 +0100 Message-ID: <5D1A7985295922448D5550C94DE291808D58F8@DEEXC1U01.de.lucent.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FE4A7E2@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTPNuiHcDprT12TGqkqbICsqtdOQABwKjwAADLZ7AAGPQX0A== From: "Drage, Keith \(Keith\)" To: "Samir Srivastava" , "Francois Audet" , "Jonathan Rosenberg" X-OriginalArrivalTime: 29 Nov 2006 11:45:05.0102 (UTC) FILETIME=[CFDC86E0:01C713AB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) If you wish the IETF rules allow you to do this. To make very clear the position: If you wish to achieve what you want, which is deprecation of various requirements in RFC 3261, then you have already been asked to provide the appropriate discussion material to this internet-draft. Part of the output of the internet-draft is to make recommendations on improvement, which can include deprecation. But we want to see the WG making an informed decision, based on a clear understanding of what is the impact on existing implementations, why the existing mechanism causes damage in the community, and so on. The scope of the internet-draft is made very clear in the slides (http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) - see slide 2. Regards Keith > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com]=20 > Sent: 28 November 2006 23:45 > To: Francois Audet; Jonathan Rosenberg > Cc: SIP WG; Drage, Keith (Keith); Dean Willis > Subject: RE: [Sip] Re: SIPS and the PSTN >=20 >=20 > IMHO, after SIPS we are committing one more mistake. After=20 > knowing SIPS is completely broken, we are attempting to=20 > justify the need on the charter. I am failing to see the=20 > value of any these documents. Rather go to IESG directly and=20 > get this milestone removed from the charter. All this is=20 > merely wastage of cycles. BTW, I don't want to open the=20 > complete ranting mode now. >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Tuesday, November 28, 2006 3:23 PM > > To: Jonathan Rosenberg > > Cc: SIP WG; Drage, Keith (Keith); Dean Willis > > Subject: RE: [Sip] Re: SIPS and the PSTN > >=20 > > Yeah, except that I've been instructed by the Chairs that this > document > > is 'informational' only. > >=20 > > I assume that it means that I can't make normative=20 > statements of any=20 > > kind. Is this true? > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 06:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpO1E-0003xn-Mw; Wed, 29 Nov 2006 06:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpO1D-0003xg-Je for sip@ietf.org; Wed, 29 Nov 2006 06:54:27 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpO1C-0005uj-8s for sip@ietf.org; Wed, 29 Nov 2006 06:54:27 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kATBlBI22217; Wed, 29 Nov 2006 06:47:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 05:54:17 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FEB3D22@zrc2hxm2.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE291808D58F8@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTPNuiHcDprT12TGqkqbICsqtdOQABwKjwAADLZ7AAGPQX0AAAYixw From: "Samir Srivastava" To: "Drage, Keith \(Keith\)" , "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Let me ask a question straigtaway who would like to use SIPS ? There was no voting/hum was done on the need of this doc in the meeting. I questioned in the meeting the need of the doc. On which Dean replied that we have similar for email etc. email is used, I can agree. But we know that this will not be used. Do you want to spend cycles on documenting/discussing for just gaguing the implementor's pain versus the complete brokenness of SIPS.=20 Tell me where it is useful? It cannot be even used in the protected network, where event watchers etc are involved. If you are one of the implementers, then do the proper analysis before implementing. Thx Samir >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 >Sent: Wednesday, November 29, 2006 3:45 AM >To: Srivastava, Samir (SC100:8826); Audet, Francois=20 >(SC100:3055); Jonathan Rosenberg >Cc: SIP WG; Dean Willis >Subject: RE: [Sip] Re: SIPS and the PSTN > >(As WG chair) > >If you wish the IETF rules allow you to do this. > >To make very clear the position: > >If you wish to achieve what you want, which is deprecation of=20 >various requirements in RFC 3261, then you have already been=20 >asked to provide the appropriate discussion material to this=20 >internet-draft. Part of the output of the internet-draft is to=20 >make recommendations on improvement, which can include=20 >deprecation. But we want to see the WG making an informed=20 >decision, based on a clear understanding of what is the impact=20 >on existing implementations, why the existing mechanism causes=20 >damage in the community, and so on. > >The scope of the internet-draft is made very clear in the slides >(http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) -=20 >see slide 2. > >Regards > >Keith > >> -----Original Message----- >> From: Samir Srivastava [mailto:samirsr@nortel.com] >> Sent: 28 November 2006 23:45 >> To: Francois Audet; Jonathan Rosenberg >> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >> Subject: RE: [Sip] Re: SIPS and the PSTN >>=20 >>=20 >> IMHO, after SIPS we are committing one more mistake. After knowing=20 >> SIPS is completely broken, we are attempting to justify the need on=20 >> the charter. I am failing to see the value of any these documents.=20 >> Rather go to IESG directly and get this milestone removed from the=20 >> charter. All this is merely wastage of cycles. BTW, I don't want to=20 >> open the complete ranting mode now. >>=20 >> Thx >> Samir >>=20 >> > -----Original Message----- >> > From: Audet, Francois (SC100:3055) >> > Sent: Tuesday, November 28, 2006 3:23 PM >> > To: Jonathan Rosenberg >> > Cc: SIP WG; Drage, Keith (Keith); Dean Willis >> > Subject: RE: [Sip] Re: SIPS and the PSTN >> >=20 >> > Yeah, except that I've been instructed by the Chairs that this >> document >> > is 'informational' only. >> >=20 >> > I assume that it means that I can't make normative >> statements of any >> > kind. Is this true? >> >=20 >>=20 >>=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 07:10:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOGA-0006qI-Iu; Wed, 29 Nov 2006 07:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOG8-0006pz-8g for sip@ietf.org; Wed, 29 Nov 2006 07:09:52 -0500 Received: from web52907.mail.yahoo.com ([206.190.49.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpOG6-0001jS-0k for sip@ietf.org; Wed, 29 Nov 2006 07:09:52 -0500 Received: (qmail 74493 invoked by uid 60001); 29 Nov 2006 12:03:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Nf658dJYnuSFMx9BK8ZAdxNvlO6uHwKiI3JJ4wL/+X3cGLRkMGVRidUH72GaF2e9IXbIFMyJEfymaa4Mpk1eqUHkas/Y71mFjLhgA/cYAPK9YydYbYY2mfPx/5DSEFJrMVaeoaypF0+8M5gkt4kY8Qwhr2klzITgyBrX1EjsCoM=; X-YMail-OSG: VCrPPpcVM1kVinn71wpfZbddNFA5cC8RRljRYHlXH.uc_qaTBaPdfU6W5VAkopZjrCYtuR3XA_KKSXS9XUxoe0avtuj6aS4qe5cMo4GN1koopQzSGxa2xUAhbzULIzWNpnhSLwsOXtJlGQ-- Received: from [217.33.106.234] by web52907.mail.yahoo.com via HTTP; Wed, 29 Nov 2006 04:03:09 PST Date: Wed, 29 Nov 2006 04:03:09 -0800 (PST) From: Raj To: SIP forum , SIP forum , SIP forum , SIP Resiprocate MIME-Version: 1.0 Message-ID: <351054.74466.qm@web52907.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Sip] List of SoftPhones available X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1119060547==" Errors-To: sip-bounces@ietf.org --===============1119060547== Content-Type: multipart/alternative; boundary="0-1037029922-1164801789=:74466" Content-Transfer-Encoding: 8bit --0-1037029922-1164801789=:74466 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Can any one give me the list of SIP and H323 Softphones available in the market now? I want to analyse all the softphones to understand the message exchange that takes place. Thanks in advance with regards Raj. --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business. --0-1037029922-1164801789=:74466 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
              Can any one give me the list of SIP and H323 Softphones available in the market now? I want to analyse all the softphones to understand the message exchange that takes place.
 
Thanks in advance
 
with regards
Raj.

Want to start your own business? Learn how on Yahoo! Small Business. --0-1037029922-1164801789=:74466-- --===============1119060547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1119060547==-- From sip-bounces@ietf.org Wed Nov 29 07:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOK5-0000eF-UR; Wed, 29 Nov 2006 07:13:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOK5-0000e6-02 for sip@ietf.org; Wed, 29 Nov 2006 07:13:57 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpOJw-0002jQ-UM for sip@ietf.org; Wed, 29 Nov 2006 07:13:56 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATCDj605617; Wed, 29 Nov 2006 07:13:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 06:13:14 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FEB3D28@zrc2hxm2.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE291808D58F8@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTPNuiHcDprT12TGqkqbICsqtdOQABwKjwAADLZ7AAGPQX0AABLqNg From: "Samir Srivastava" To: "Drage, Keith \(Keith\)" , "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would like to have the chair's permission for the voting on the need of this document on the list. Who would like to see this document to progress ? Thx Samir=20 >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 >Sent: Wednesday, November 29, 2006 3:45 AM >To: Srivastava, Samir (SC100:8826); Audet, Francois=20 >(SC100:3055); Jonathan Rosenberg >Cc: SIP WG; Dean Willis >Subject: RE: [Sip] Re: SIPS and the PSTN > >(As WG chair) > >If you wish the IETF rules allow you to do this. > >To make very clear the position: > >If you wish to achieve what you want, which is deprecation of=20 >various requirements in RFC 3261, then you have already been=20 >asked to provide the appropriate discussion material to this=20 >internet-draft. Part of the output of the internet-draft is to=20 >make recommendations on improvement, which can include=20 >deprecation. But we want to see the WG making an informed=20 >decision, based on a clear understanding of what is the impact=20 >on existing implementations, why the existing mechanism causes=20 >damage in the community, and so on. > >The scope of the internet-draft is made very clear in the slides >(http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) -=20 >see slide 2. > >Regards > >Keith > >> -----Original Message----- >> From: Samir Srivastava [mailto:samirsr@nortel.com] >> Sent: 28 November 2006 23:45 >> To: Francois Audet; Jonathan Rosenberg >> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >> Subject: RE: [Sip] Re: SIPS and the PSTN >>=20 >>=20 >> IMHO, after SIPS we are committing one more mistake. After knowing=20 >> SIPS is completely broken, we are attempting to justify the need on=20 >> the charter. I am failing to see the value of any these documents.=20 >> Rather go to IESG directly and get this milestone removed from the=20 >> charter. All this is merely wastage of cycles. BTW, I don't want to=20 >> open the complete ranting mode now. >>=20 >> Thx >> Samir >>=20 >> > -----Original Message----- >> > From: Audet, Francois (SC100:3055) >> > Sent: Tuesday, November 28, 2006 3:23 PM >> > To: Jonathan Rosenberg >> > Cc: SIP WG; Drage, Keith (Keith); Dean Willis >> > Subject: RE: [Sip] Re: SIPS and the PSTN >> >=20 >> > Yeah, except that I've been instructed by the Chairs that this >> document >> > is 'informational' only. >> >=20 >> > I assume that it means that I can't make normative >> statements of any >> > kind. Is this true? >> >=20 >>=20 >>=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 08:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPDI-0005Vk-7N; Wed, 29 Nov 2006 08:11:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPDG-0005Vf-Qm for sip@ietf.org; Wed, 29 Nov 2006 08:10:58 -0500 Received: from web52913.mail.yahoo.com ([206.190.49.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpPDE-0007GN-J3 for sip@ietf.org; Wed, 29 Nov 2006 08:10:58 -0500 Received: (qmail 42824 invoked by uid 60001); 29 Nov 2006 13:10:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rw/MaEb0GltV9jOXWL/a96XyZDdBhMLtQHXCkp0eGXRsiatuiyLssl50ZK6yznrvWi0oPrg1C24asB0QfWXEgXsgPBQhHTkP0rUOxwNfaJwFa9gB2MFY/7X2MnsP+98WPufUzMZ3mmpgKqBfXjwLMftZFz/Orquj9fG6oXrNXkg=; X-YMail-OSG: Gws7x5QVM1mTkZXEdYiCJdbmQEy0wXFml1QVlKhQCmSrbEAgSaWbPq2GO04C4xdlYw-- Received: from [217.33.106.234] by web52913.mail.yahoo.com via HTTP; Wed, 29 Nov 2006 05:10:51 PST Date: Wed, 29 Nov 2006 05:10:51 -0800 (PST) From: Raj To: SIP forum MIME-Version: 1.0 Message-ID: <326330.41992.qm@web52913.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Signalling and media path of SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1782684884==" Errors-To: sip-bounces@ietf.org --===============1782684884== Content-Type: multipart/alternative; boundary="0-915991800-1164805851=:41992" Content-Transfer-Encoding: 8bit --0-915991800-1164805851=:41992 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Recently I read from an article that signalling path of SIP is different from the path of media. When two end points want to communicate using SIP, the signalling takes place according to the operation of SIP, but once the signalling is over and when the media channel has to be established, which protocol is used to find the optimal media path? Moreover, when the session has to be terminated, SIP enabled end point has to send the BYE request, in this case, whether it takes the same path of INVITE request(which initiated the session) or a different one. I am considering the stateless proxies to be in the network. with regards Raj. --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. --0-915991800-1164805851=:41992 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
              Recently I read from an article that signalling path of SIP is different from the path of media. When two end points want to communicate using SIP, the signalling takes place according to the operation of SIP, but once the signalling is over and when the media channel has to be established, which protocol is used to find the optimal media path?
 
             Moreover, when the session has to be terminated, SIP enabled end point has to send the BYE request, in this case, whether it takes the same path of INVITE request(which initiated the session) or  a different one. I am considering the stateless proxies to be in the network.
 
with regards
Raj.

Everyone is raving about the all-new Yahoo! Mail beta. --0-915991800-1164805851=:41992-- --===============1782684884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1782684884==-- From sip-bounces@ietf.org Wed Nov 29 09:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQ8l-0000bt-C1; Wed, 29 Nov 2006 09:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQ8j-0000aG-2z for sip@ietf.org; Wed, 29 Nov 2006 09:10:21 -0500 Received: from web52807.mail.yahoo.com ([206.190.48.250]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpQ8g-0001pt-Dx for sip@ietf.org; Wed, 29 Nov 2006 09:10:21 -0500 Received: (qmail 37640 invoked by uid 60001); 29 Nov 2006 14:03:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=twq0bMfMBmByBX4wc6naSjnx7+l9T+EqRX0YUKQ0TPWsaauJNPGbxj1IeY2ZWybQIBMG1WgfxU8gMZQDTf6FxvT44sCKoLrC88a9bGVBOFKKjns/rklT0KU11UfwMucHg6l1JbwFepf3XnexPvvXFA8YYYFZ1ywb6JpM4e97i3Q= ; Message-ID: <20061129140338.37638.qmail@web52807.mail.yahoo.com> Received: from [47.168.54.136] by web52807.mail.yahoo.com via HTTP; Wed, 29 Nov 2006 06:03:38 PST Date: Wed, 29 Nov 2006 06:03:38 -0800 (PST) From: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= Subject: Re: [Sip] automatically switches to TCP To: manjunathwarad@huawei.com, "Xia, Zhi Feng \(Bruce\)" , IETF SIP List MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573845408==" Errors-To: sip-bounces@ietf.org --===============1573845408== Content-Type: multipart/alternative; boundary="0-123863286-1164809018=:37631" --0-123863286-1164809018=:37631 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable the reference given below is about; in case TCP selected due to message siz= e constraints but not supported then jump to UDP situation, however vice v= ersa not being pointed still.=0A=0A=0A----- Original Message ----=0AFrom: M= anjunath Warad =0ATo: "Xia, Zhi Feng (Bruce)" ; IETF SIP List =0ASent: Tuesday, November 2= 8, 2006 7:20:17 AM=0ASubject: RE: [Sip] automatically switches to TCP=0A=0A= =0AHi Bruce,=0A See inline...=0A =0ARegards,=0AManju=0A*****************= **********************************************************************=0A = This e-mail and attachments contain confidential information from= HUAWEI, which is intended only for the person or entity whose address is l= isted above. Any use of the information contained herein in any way (includ= ing, but not limited to, total or partial disclosure, reproduction, or diss= emination) by persons other than the intended recipient's) is prohibited. I= f you receive this e-mail in error, please notify the sender by phone or em= ail immediately and delete it!=0A =0A=0A=0A=0A=0AFrom: Xia, Zhi Feng (Bruce= ) [mailto:brucex@lucent.com] =0ASent: Monday, November 27, 2006 2:27 PM=0AT= o: manjunathwarad@huawei.com; IETF SIP List=0ASubject: RE: [Sip] automatica= lly switches to TCP=0A=0A=0AHi Manju,=0A1. Is this documented somewhere? = =0A About switching of protocol, it is documented in RFC 3261 in sec 18.= 1.1.=0A =0A"If an element sends a request over TCP because of these message= size=0Aconstraints, and that request would have otherwise been sent over= =0AUDP, if the attempt to establish the connection generates either an=0AIC= MP Protocol Not Supported, or results in a TCP reset, the element=0ASHOULD = retry the request, using UDP. This is only to provide=0Abackwards compatibi= lity with RFC 2543 compliant implementations that=0Ado not support TCP. It = is anticipated that this behavior will be=0Adeprecated in a future revision= of this specification. " =0A =0A About transaction moving to terminated= state, check in the transaction part of RFC 3261.=0A =0A2. We had a stack = which sends messages over UDP as mandated by UA, if UDP failure or transact= ion timeout(e.g. after 7 retrys of INVITE) it switches to TCP instead of go= ing into terminated state -- this sounds violate your "MUST"?=0A I am no= t sure why this behaviour is implemented; however, I think this is violati= on of standard.=0A =0AThanks,=0ABruce=0A-----Original Message-----=0AFrom: = Manjunath Warad [mailto:manjunathwarad@huawei.com]=0ASent: 2006?11?24? 11:0= 7 PM=0ATo: 'Xia, Zhi Feng (Bruce)'; 'IETF SIP List'=0ASubject: RE: [Sip] au= tomatically switches to TCP=0A=0A=0AHi Bruce,=0A I think this is other w= ay round, if sending on TCP fails then it is recommended to try on UDP to k= eep the backward compatibility with RFC 2543. =0AAfter timeout transaction = MUST enter into terminated state and will not retry by changing the protoco= l.=0A =0ARegards,=0AManju=0A =0A*******************************************= ********************************************=0A This e-mail and = attachments contain confidential information from HUAWEI, which is intended= only for the person or entity whose address is listed above. Any use of th= e information contained herein in any way (including, but not limited to, t= otal or partial disclosure, reproduction, or dissemination) by persons othe= r than the intended recipient's) is prohibited. If you receive this e-mail = in error, please notify the sender by phone or email immediately and delete= it!=0A =0A=0A=0A=0A=0AFrom: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.co= m] =0ASent: Friday, November 24, 2006 4:47 PM=0ATo: IETF SIP List=0ASubject= : [Sip] automatically switches to TCP=0A=0A=0AHi,=0AThere're many implement= ations when transportation on UDP fails or transation timeout without respo= nse it will automatically try TCP connection. Is this mandated in any RFCs?= I think RFC3261 says if transaction timeouts it should go to terminated st= ate.=0A =0AIs this implementation a violation to RFC3261?=0A =0AThanks,=0AB= ruce=0A_______________________________________________=0ASip mailing list = https://www1.ietf.org/mailman/listinfo/sip=0AThis list is for NEW developme= nt of the core SIP Protocol=0AUse sip-implementors@cs.columbia.edu for ques= tions on current sip=0AUse sipping@ietf.org for new developments on the app= lication of sip --0-123863286-1164809018=:37631 Content-Type: text/html; charset=iso-2022-jp
the reference given below is about; in case TCP selected due to message size constraints but not supported then jump to UDP situation,  however vice versa not being pointed still.

----- Original Message ----
From: Manjunath Warad <manjunathwarad@huawei.com>
To: "Xia, Zhi Feng (Bruce)" <brucex@lucent.com>; IETF SIP List <sip@ietf.org>
Sent: Tuesday, November 28, 2006 7:20:17 AM
Subject: RE: [Sip] automatically switches to TCP

Hi Bruce,
    See inline...
 
Regards,
Manju

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com]
Sent: Monday, November 27, 2006 2:27 PM
To: manjunathwarad@huawei.com; IETF SIP List
Subject: RE: [Sip] automatically switches to TCP

Hi Manju,
1. Is this documented somewhere?  
    About switching of protocol, it is documented in RFC 3261 in sec 18.1.1.
 
"If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP. This is only to provide
backwards compatibility with RFC 2543 compliant implementations that
do not support TCP. It is anticipated that this behavior will be
deprecated in a future revision of this specification. " 
 
    About transaction moving to terminated state, check in the transaction part of RFC 3261.
 
2. We had a stack which sends messages over UDP as mandated by UA, if UDP failure or transaction timeout(e.g. after 7 retrys of INVITE) it switches to TCP instead of going into terminated state -- this sounds violate your "MUST"?
    I am not sure why this behaviour is implemented; however,  I think this is violation of standard.
 
Thanks,
Bruce
-----Original Message-----
From: Manjunath Warad [mailto:manjunathwarad@huawei.com]
Sent: 2006?11?24? 11:07 PM
To: 'Xia, Zhi Feng (Bruce)'; 'IETF SIP List'
Subject: RE: [Sip] automatically switches to TCP

Hi Bruce,
    I think this is other way round, if sending on TCP fails then it is recommended to try on UDP to keep the backward compatibility with RFC 2543.
After timeout transaction MUST enter into terminated state and will not retry by changing the protocol.
 
Regards,
Manju
 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Xia, Zhi Feng (Bruce) [mailto:brucex@lucent.com]
Sent: Friday, November 24, 2006 4:47 PM
To: IETF SIP List
Subject: [Sip] automatically switches to TCP

Hi,
There're many implementations when transportation on UDP fails or transation timeout without response it will automatically try TCP connection. Is this mandated in any RFCs? I think RFC3261 says if transaction timeouts it should go to terminated state.
 
Is this implementation a violation to RFC3261?
 
Thanks,
Bruce
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

--0-123863286-1164809018=:37631-- --===============1573845408== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1573845408==-- From sip-bounces@ietf.org Wed Nov 29 09:17:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQEg-0005kV-Bs; Wed, 29 Nov 2006 09:16:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQEe-0005k6-LT for sip@ietf.org; Wed, 29 Nov 2006 09:16:28 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpQEa-0003JY-86 for sip@ietf.org; Wed, 29 Nov 2006 09:16:28 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1568507ugd for ; Wed, 29 Nov 2006 06:16:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nnnkfdK4WKZrFoOfZBI79NxhhTITMa8c7ONBv9SjXtMmol71zWVViiU8M6pbcGAhJoFJnPNXnhd2moRVU1J15EmTtv68Y/WJBie8SkMonXddk3C9YkPQm7V20dGJJAlLuifoll9jt0RqZQn1cYXsonf212dkn66UhPNijRNvJvs= Received: by 10.67.89.5 with SMTP id r5mr3415675ugl.1164809782952; Wed, 29 Nov 2006 06:16:22 -0800 (PST) Received: by 10.66.251.4 with HTTP; Wed, 29 Nov 2006 06:16:22 -0800 (PST) Message-ID: <6916dea20611290616i401673c9g621bd84e797c21aa@mail.gmail.com> Date: Wed, 29 Nov 2006 06:16:22 -0800 From: "Alexandre Passito" To: sip@ietf.org Subject: Re: [Sip] List of SoftPhones available In-Reply-To: <351054.74466.qm@web52907.mail.yahoo.com> MIME-Version: 1.0 References: <351054.74466.qm@web52907.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0100056253==" Errors-To: sip-bounces@ietf.org --===============0100056253== Content-Type: multipart/alternative; boundary="----=_Part_43561_13200763.1164809782891" ------=_Part_43561_13200763.1164809782891 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline You can take a look at: www.voip-info.org ;) 2006/11/29, Raj : > > Hello, > > Can any one give me the list of SIP and H323 Softphones > available in the market now? I want to analyse all the softphones to > understand the message exchange that takes place. > > Thanks in advance > > with regards > Raj. > > ------------------------------ > Want to start your own business? Learn how on Yahoo! Small Business. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > --=20 --=20 Alexandre Passito - Estudante de Mestrado Universidade Federal do Amazonas (UFAM) Departamento de Ci=EAncia da Computa=E7=E3o (DCC) -- Alexandre Passito - M.Sc. Student Federal University of Amazonas (UFAM) Computer Science Department (DCC) -- E-mail: passito at dcc.ufam.edu.br Web: www.dcc.ufam.edu.br/~passito Manaus - AM - Brasil ------=_Part_43561_13200763.1164809782891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline You can take a look at:

www.voi= p-info.org

;)

2006/11/29= , Raj <ponrajit@yahoo.com>:=
Hello,
=
 
        &= nbsp;     Can any one give me the list of SIP and H323 = Softphones available in the market now? I want to analyse all the softphone= s to understand the message exchange that takes place.
 
Thanks in advance
 
=
with regards
Raj.

=20

Want to start your own business? Learn how on htt= ps://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for qu= estions on current sip
Use sipping@ietf.org for new developments on the = application of sip




-- <= br> --
Alexandre Passito - Estudante de Mestrado
Universidade Federal do= Amazonas (UFAM)        
Departa= mento de Ci=EAncia da Computa=E7=E3o (DCC)  
--
Alexandre P= assito - M.Sc. Student        
F= ederal University of Amazonas (UFAM)      &nb= sp;   
Computer Science Department (DCC)      &n= bsp;     
--
E-mail: passito at dcc.ufam.edu.br     &nb= sp;
Web: www.dcc.ufam.ed= u.br/~passito         
Manaus - AM - Brasil&nb= sp;  ------=_Part_43561_13200763.1164809782891-- --===============0100056253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0100056253==-- From sip-bounces@ietf.org Wed Nov 29 09:29:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQQg-0002Pd-3W; Wed, 29 Nov 2006 09:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQQf-0002PX-FU for sip@ietf.org; Wed, 29 Nov 2006 09:28:53 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpQQd-00068q-Ub for sip@ietf.org; Wed, 29 Nov 2006 09:28:53 -0500 Received: from bg0007avexu1.global.avaya.com (h135-64-19-8.avaya.com [135.64.19.8]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kATESn7O002661 for ; Wed, 29 Nov 2006 09:28:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] List of SoftPhones available Date: Wed, 29 Nov 2006 15:28:49 +0100 Message-ID: <28F8C2F947AE9940BD5C097671AC64C503D764A4@bg0007avexu1.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] List of SoftPhones available Thread-Index: AccTwVztx5sWvHnTRTKa7LQdyExj5AAASoJg From: "Dietrich, Wolfgang \(Wolfgang\)" To: "Alexandre Passito" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 1.8 (+) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560423103==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1560423103== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C713C2.AF645D11" This is a multi-part message in MIME format. ------_=_NextPart_001_01C713C2.AF645D11 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, i have some SIP phones with soft PBX on board: http://www1.avaya.com/campaign/demo/one-x/ = =20 please let me know if you are interessted in testing, i start with fieldtests now! brgds =20 Wolfgang _____ =20 From: Alexandre Passito [mailto:alexandre.passito@gmail.com]=20 Sent: Wednesday, November 29, 2006 3:16 PM To: sip@ietf.org Subject: Re: [Sip] List of SoftPhones available You can take a look at: www.voip-info.org ;) 2006/11/29, Raj :=20 Hello, =20 Can any one give me the list of SIP and H323 Softphones = available in the market now? I want to analyse all the softphones to = understand the message exchange that takes place.=20 =20 Thanks in advance =20 with regards =09 Raj. =09 _____ =20 Want to start your own business? Learn how on Yahoo! Small Business. = =20 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip =09 =09 --=20 --=20 Alexandre Passito - Estudante de Mestrado Universidade Federal do Amazonas (UFAM) =20 Departamento de Ci=EAncia da Computa=E7=E3o (DCC) =20 -- Alexandre Passito - M.Sc. Student =20 Federal University of Amazonas (UFAM) =20 Computer Science Department (DCC) =20 -- E-mail: passito at dcc.ufam.edu.br =20 Web: www.dcc.ufam.edu.br/~passito =20 Manaus - AM - Brasil =20 ------_=_NextPart_001_01C713C2.AF645D11 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
i have some SIP phones with soft PBX  = on=20 board:
please=20 let me know if you are interessted in testing,
i=20 start with fieldtests now!
brgds
 
Wolfgang

From: Alexandre Passito=20 [mailto:alexandre.passito@gmail.com]
Sent: Wednesday, = November 29,=20 2006 3:16 PM
To: sip@ietf.org
Subject: Re: [Sip] = List of=20 SoftPhones available

You can take a look at:

www.voip-info.org

;)

=
2006/11/29, Raj <ponrajit@yahoo.com>:=20
Hello,
 
=
           &n= bsp; =20 Can any one give me the list of SIP and H323 Softphones available in = the=20 market now? I want to analyse all the softphones to understand the = message=20 exchange that takes place.
 
Thanks in advance
 
with regards
Raj.

Want to start your own business? Learn how on Yahoo! Small Business. =


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




--
--=20
Alexandre Passito - Estudante de Mestrado
Universidade Federal do = Amazonas = (UFAM)        
Departamento=20 de Ci=EAncia da Computa=E7=E3o (DCC)  
--
Alexandre = Passito - M.Sc.=20 Student        
Federal = University of=20 Amazonas = (UFAM)          =20
Computer Science Department=20 (DCC)           &n= bsp;
--
E-mail:=20 passito at dcc.ufam.edu.br   &nbs= p;  
Web:=20 www.dcc.ufam.edu.br/~passito= =20         
Manaus - AM -=20 Brasil   ------_=_NextPart_001_01C713C2.AF645D11-- --===============1560423103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1560423103==-- From sip-bounces@ietf.org Wed Nov 29 09:56:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQr1-0006Kv-KK; Wed, 29 Nov 2006 09:56:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQr0-0006Ko-DZ for sip@ietf.org; Wed, 29 Nov 2006 09:56:06 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpQqx-0002XY-PT for sip@ietf.org; Wed, 29 Nov 2006 09:56:06 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1GpQqp-0001cw-8z; Wed, 29 Nov 2006 06:55:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 06:55:54 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC5D4276@sea02-mxc01.citel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C9854@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTNj38voVwF9QMRXKXzZRbGjAANAAAeb7wACNGQJA= From: "Michael Procter" To: "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "Joel M. Halpern" , SIP WG , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Personally, I think that the initial qualifying phrase of the last paragraph is potentially ambiguous: If a B2BUA is used in lieu of a proxy (as is common in practical deployment), if it receives... Could this be removed and an explanatory sentence appended to the paragraph to make it read more like: If a B2BUA (Back to Back User Agent) receives a request destined to a SIPS Request-URI that does not identify itself and it forwards it on towards that Request-URI, it must use a SIPS Request-URI on the outgoing connection as well. This can occur when a B2BUA is used in lieu of a proxy (as is common in practical deployments). As to whether 'must' should be MUST or must or SHOULD or should, I'll leave that to you! Regards, Michael > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 28 November 2006 22:10 > To: Jonathan Rosenberg > Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean Willis > Subject: RE: [Sip] Re: SIPS and the PSTN >=20 > What about this: >=20 >=20 > 3.1. Scope of SIPS >=20 > It is outside of the scope of this document to specify what happens > when a SIPS URI identifies a UAS that "maps" outside of the SIP > network. For example, to other networks such as the PSTN or an H.323 > network. These networks have their own standards on what is > appropriate security level >=20 > If a B2BUA is used in lieu of a proxy (as is common in practical > deployment), > if it receives a request destined to a SIPS Request-URI that does not > identify itself > and it forwards it on towards that Request-URI, it must use a > SIPS Request-URI on the outgoing connection as well. >=20 >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Tuesday, November 28, 2006 13:43 > > To: Audet, Francois (SC100:3055) > > Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; > > Dean Willis > > Subject: Re: [Sip] Re: SIPS and the PSTN > > > > I must say I'm a bit worried about 'should'. I think Dean > > raised this point; since tons of "proxies" todays are also > > b2bua's in some sense (that is, they do things a pure proxy > > cannot), this may very well reduce the overall effectiveness > > of sips to just SHOULD use TLS. That seems ever looser than > > what we have today. > > > > I'd rather not try to define what constitutes a b2bua that > > can downgrade sips, and what kind of b2bua cannot. Instead, > > it seems easier to simply state that if you are not the > > target of the sips URI, and you have a SIP next-hop, you MUST > > use TLS on that hop. > > > > -Jonathan R. > > > > Francois Audet wrote: > > > > > Agreed, that's why it's a should, and that's why that section is > > > short... > > > > > > Are we OK with the wording? > > > > > > And remember: concrete proposals... > > > > > > > > > > > >>-----Original Message----- > > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>Sent: Tuesday, November 28, 2006 08:42 > > >>To: Audet, Francois (SC100:3055) > > >>Cc: Dean Willis; Joel M. Halpern; SIP WG > > >>Subject: Re: [Sip] Re: SIPS and the PSTN > > >> > > >>I think I am ok with SHOULD for B2BUAs, but I still think > > it is hard > > >>to be specific because of the wide variety of things that > > B2BUAs can > > >>do. > > >> > > >>Consider a different kind of B2BUA - a conference focus. If > > it allows > > >>connections via SIPS, should it require all connections to be SIPS? > > >>While that might be a policy for some conferences, I don't > > think it is > > >>the only reasonable policy. > > >> > > >> Paul > > >> > > >>Francois Audet wrote: > > >> > > >>>Let's try to write up something for the document. > > >>>I am pretty sure that I remember that in essence, what we > > >> > > >>decided was > > >> > > >>>that: > > >>>1) Anything outside SIP network is out-of-scope > > >>>2) B2BUA SHOULD preserve SIPS on both sides. (It was also > > said that > > >>>there ain't nothing we > > >>> can do to enforce it of course). > > >>> > > >>>Here is a strawman: > > >>> > > >>> 3.1. Scope of SIPS > > >>> > > >>> It is outside of the scope of this document to specify > > >> > > >>what happens > > >> > > >>> when a SIPS URI defines a UAS that "maps" outside of the > > >> > > >>SIP network. > > >> > > >>> For example, to other networks such as the PSTN or an > > >> > > >>H.323 network. > > >> > > >>> These networks have their own standards on what is appropriate > > >>> security levels. > > >>> > > >>> Derived connections in SIP however should use SIPS > > >> > > >>end-to-end, even > > >> > > >>> accross distinct SIP networks. For example, If a > > >> > > >>Back-to-Back-User- > > >> > > >>> Agent (B2BUA) receives a request destined to a SIPS > > >> > > >>Request-URI and > > >> > > >>> it forwards it, it should use a SIPS Request-URI on the outgoing > > >>> connection as well. This could happen for example when > > >> > > >>the B2BUA is > > >> > > >>> Session Border Controller sitting between two SIP > > >> > > >>networks. It could > > >> > > >>> also happen in an Application Server or with SIP > > third-party call > > >>> control [RFC3725]. > > >>> > > >> > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 10:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRXq-0004le-MG; Wed, 29 Nov 2006 10:40:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRXp-0004lN-DP for sip@ietf.org; Wed, 29 Nov 2006 10:40:21 -0500 Received: from web52910.mail.yahoo.com ([206.190.49.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpRXN-0002sF-NY for sip@ietf.org; Wed, 29 Nov 2006 10:40:21 -0500 Received: (qmail 27050 invoked by uid 60001); 29 Nov 2006 15:39:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ofunls+1vONqhJLv1JUXUCVLDG7n91xZNuD9D+7je5A8vxXTftp71bsH/amH0FGPB6xUJk8TNPkhF5gZHROvqrUBA3kJcFwKGUrL2BRy78pbF1w6AuMIOOuoxYutAmbxjyrE68DxrqXzuUM3Tgfq3kqzJgfTu6bRDZ8tmqMcoVM= ; Message-ID: <20061129153953.27048.qmail@web52910.mail.yahoo.com> X-YMail-OSG: 8dg_6m8VM1mJO2pPhyAXYuxUDRLsfxDyO.GbyWsg00pHyVDf6IOU0ErNpUu2EcXJO1l3.X6cqt28NHfzxdpLXQ55TSAxkRCMgOoIy_kHgVZ_ieDtLzcisq.tIslrpE0tX4XgwX84KvIFag-- Received: from [217.33.106.234] by web52910.mail.yahoo.com via HTTP; Wed, 29 Nov 2006 07:39:53 PST Date: Wed, 29 Nov 2006 07:39:53 -0800 (PST) From: Raj To: SIP forum MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Signalling time - regarding X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478179385==" Errors-To: sip-bounces@ietf.org --===============0478179385== Content-Type: multipart/alternative; boundary="0-113463866-1164814793=:26413" Content-Transfer-Encoding: 8bit --0-113463866-1164814793=:26413 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello to all, I read an article about Skype and it was stated that it takes 2 to 3 seconds for session establishment. Can anyone tell me how long will it take for SIP for session establishment? with regards Raj --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business. --0-113463866-1164814793=:26413 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello to all,
 
              I read an article about Skype and it was stated that it takes 2 to 3 seconds for session establishment. Can anyone tell me how long will it take for SIP for session establishment?
 
with regards
Raj

Want to start your own business? Learn how on Yahoo! Small Business. --0-113463866-1164814793=:26413-- --===============0478179385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0478179385==-- From sip-bounces@ietf.org Wed Nov 29 10:48:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRfa-0007qz-A9; Wed, 29 Nov 2006 10:48:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRfY-0007qa-Tf for sip@ietf.org; Wed, 29 Nov 2006 10:48:20 -0500 Received: from sitemail.everyone.net ([216.200.145.35] helo=omta16.mta.everyone.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRfX-0004K3-DS for sip@ietf.org; Wed, 29 Nov 2006 10:48:20 -0500 Received: from dm16.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta16.mta.everyone.net (Postfix) with ESMTP id BCA3042496; Wed, 29 Nov 2006 07:48:18 -0800 (PST) X-Eon-Dm: dm16 Received: by dm16.mta.everyone.net (EON-AUTHRELAY2[SSL] - cf31a202) id dm16.456a482d.92518; Wed, 29 Nov 2006 07:48:16 -0800 X-Eon-Sig: AQIH5JVFbavA9bjWrgIAAAAC,aa11d736cc4641c2014fea6012e27c9e From: "Bala Neelakantan" To: "'Raj'" , "'SIP forum'" Subject: RE: [Sip] Signalling time - regarding Date: Wed, 29 Nov 2006 09:48:24 -0600 Message-ID: <001c01c713cd$d10caa00$723cd14c@NeelLT> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20061129153953.27048.qmail@web52910.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balasubramanian_neelakantan@quintum.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0914009690==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0914009690== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C7139B.86723A00" This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C7139B.86723A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Questions like this are addressed to SIP-Implementors mailing list. sip-implementors@cs.columbia.edu. In general the call establishment takes the typical round trip duration between the UserAgents. Typically the roundtrip could be around 500 msec. Thanks, Neel -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Raj Sent: Wednesday, November 29, 2006 9:40 AM To: SIP forum Subject: [Sip] Signalling time - regarding Hello to all, I read an article about Skype and it was stated that it takes 2 to 3 seconds for session establishment. Can anyone tell me how long will it take for SIP for session establishment? with regards Raj _____ Want to start your own business? Learn how on Yahoo! Small Business. ------=_NextPart_000_001D_01C7139B.86723A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Questions like this are addressed = to SIP-Implementors mailing list.

 

sip-implementors@cs.colu= mbia.edu.

 

In general the call establishment = takes the typical round trip duration between the UserAgents.  Typically the roundtrip could be around 500 msec.

 

Thanks,

Neel

 

-----Original = Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Raj
Sent: Wednesday, November = 29, 2006 9:40 AM
To: SIP forum
Subject: [Sip] Signalling = time - regarding

 

Hello to all,

 

       &nbs= p;      I read an article about Skype and it was stated that it takes 2 to 3 = seconds for session establishment. Can anyone tell me how long will it take for = SIP for session establishment?

 

with regards

Raj

 

Want to start your own business? Learn how on = Yahoo! Small Business.

------=_NextPart_000_001D_01C7139B.86723A00-- --===============0914009690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0914009690==-- From sip-bounces@ietf.org Wed Nov 29 11:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRvu-0004Zq-Ri; Wed, 29 Nov 2006 11:05:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRvt-0004Zf-VP for sip@ietf.org; Wed, 29 Nov 2006 11:05:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRvs-0007K2-JN for sip@ietf.org; Wed, 29 Nov 2006 11:05:13 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2006 08:05:09 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kATG59hr013182; Wed, 29 Nov 2006 08:05:09 -0800 Received: from [216.102.208.13] (sjc-vpn-hwcore-525.cisco.com [10.21.154.13]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kATG4rdE024236; Wed, 29 Nov 2006 08:04:53 -0800 (PST) Message-ID: <456DAFB1.8070009@cisco.com> Date: Wed, 29 Nov 2006 08:05:05 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Re: SIPS and the PSTN References: <5D1A7985295922448D5550C94DE291808D58F8@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291808D58F8@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3007; t=1164816309; x=1165680309; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20; bh=u50PLbFm9Xekh7P2q7M1bgUnfrHERqlKqXtU1jKhEw8=; b=mpn+OSLOmLsW5rliSnCxbUK5datzPzbtmb6x2ETdLYMKfS4HM7eDgtmdWLwwyTjgk+k5Aeks kRV1mkJPP7CsnqZakxsQ7tMv0AlCVC1lIa2FPB4rV2CTPDyFw3At7UmB; Authentication-Results: sj-dkim-5; header.From=mat@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: SIP WG , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This seems very much at cross purposes with Francois' draft and would just add to the confusion, IMO. What would be better is for Francois' draft to add that option along with the documentation (which in itself is like proving a negative, but I digress) and then have the working group just choose which section of the draft to delete, or insert what the ultimate choice was or something like that. I think that documenting why SIPS was or wasn't deprecated is every bit as important as clarifying the mistakes that were made initially. Mike Drage, Keith (Keith) wrote: > (As WG chair) > > If you wish the IETF rules allow you to do this. > > To make very clear the position: > > If you wish to achieve what you want, which is deprecation of various > requirements in RFC 3261, then you have already been asked to provide > the appropriate discussion material to this internet-draft. Part of the > output of the internet-draft is to make recommendations on improvement, > which can include deprecation. But we want to see the WG making an > informed decision, based on a clear understanding of what is the impact > on existing implementations, why the existing mechanism causes damage in > the community, and so on. > > The scope of the internet-draft is made very clear in the slides > (http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) - see slide 2. > > Regards > > Keith > > >> -----Original Message----- >> From: Samir Srivastava [mailto:samirsr@nortel.com] >> Sent: 28 November 2006 23:45 >> To: Francois Audet; Jonathan Rosenberg >> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >> Subject: RE: [Sip] Re: SIPS and the PSTN >> >> >> IMHO, after SIPS we are committing one more mistake. After >> knowing SIPS is completely broken, we are attempting to >> justify the need on the charter. I am failing to see the >> value of any these documents. Rather go to IESG directly and >> get this milestone removed from the charter. All this is >> merely wastage of cycles. BTW, I don't want to open the >> complete ranting mode now. >> >> Thx >> Samir >> >> >>> -----Original Message----- >>> From: Audet, Francois (SC100:3055) >>> Sent: Tuesday, November 28, 2006 3:23 PM >>> To: Jonathan Rosenberg >>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >>> Subject: RE: [Sip] Re: SIPS and the PSTN >>> >>> Yeah, except that I've been instructed by the Chairs that this >>> >> document >> >>> is 'informational' only. >>> >>> I assume that it means that I can't make normative >>> >> statements of any >> >>> kind. Is this true? >>> >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 11:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSDF-0001q3-TL; Wed, 29 Nov 2006 11:23:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRms-0000w6-8I for sip@ietf.org; Wed, 29 Nov 2006 10:55:54 -0500 Received: from sitemail.everyone.net ([216.200.145.35] helo=omta14.mta.everyone.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRmS-0005ZV-PG for sip@ietf.org; Wed, 29 Nov 2006 10:55:53 -0500 Received: from dm17.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta14.mta.everyone.net (Postfix) with ESMTP id 7E55A4443E; Wed, 29 Nov 2006 07:54:40 -0800 (PST) X-Eon-Dm: dm17 Received: by dm17.mta.everyone.net (EON-AUTHRELAY2[SSL] - cf31a202) id dm17.456a4830.923aa; Wed, 29 Nov 2006 07:54:35 -0800 X-Eon-Sig: AQIH5JVFba07nOSVPQIAAAAC,0cbd461b8baa39049307fcd0df7a0b55 From: "Bala Neelakantan" To: "'Raj'" , "'SIP forum'" Subject: RE: [Sip] Signalling and media path of SIP Date: Wed, 29 Nov 2006 09:54:46 -0600 Message-ID: <002b01c713ce$b28108a0$723cd14c@NeelLT> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <326330.41992.qm@web52913.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balasubramanian_neelakantan@quintum.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111943414==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1111943414== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C7139C.67E698A0" This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C7139C.67E698A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions like this are addressed to SIP-Implementors mailing list. =20 sip-implementors@cs.columbia.edu. =20 You may want to see some IETF example call flows. =20 In addition to RFC 3261, please refer to RFC 3665 and other BCPs on SIP. =20 To answer the question, the media could be RTP based. The media path = are between the two UAs. =20 The call signaling could be established where multiple SIP servers could = be involved. If the SIP servers needs to be in the signaling path for the duration of the call, then the Servers do Record-Route. So, a BYE or = any other requests will visit the SIP servers. If the SIP servers do not = wish to be in the path for subsequent requests, it will not record-route. =20 Thanks, Neel =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Raj Sent: Wednesday, November 29, 2006 7:11 AM To: SIP forum Subject: [Sip] Signalling and media path of SIP =20 Hello, =20 Recently I read from an article that signalling path of = SIP is different from the path of media. When two end points want to = communicate using SIP, the signalling takes place according to the operation of SIP, = but once the signalling is over and when the media channel has to be established, which protocol is used to find the optimal media path? =20 Moreover, when the session has to be terminated, SIP = enabled end point has to send the BYE request, in this case, whether it takes = the same path of INVITE request(which initiated the session) or a different one. I am considering the stateless proxies to be in the network. =20 with regards Raj. =20 _____ =20 Everyone is raving about the all-new Yahoo! Mail beta. ------=_NextPart_000_002C_01C7139C.67E698A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Questions like this are addressed = to SIP-Implementors mailing list.

 

sip-implementors@cs.colu= mbia.edu.

 

You may want to see some IETF = example call flows.

 

In addition to RFC 3261, please = refer to RFC 3665 and other BCPs on SIP.

 

To answer the question, the media = could be RTP based.  The media path are between the two = UAs.

 

The call signaling could be = established where multiple SIP servers could be involved.  If the SIP servers = needs to be in the signaling path for the duration of the call, then the Servers = do Record-Route.  So, a BYE or any other requests will visit the SIP servers.  If the SIP servers do not wish to be in the path for = subsequent requests, it will not record-route.

 

Thanks,

Neel

 

-----Original = Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Raj
Sent: Wednesday, November 29, 2006 7:11 AM
To: SIP forum
Subject: [Sip] Signalling = and media path of SIP

 

Hello,

 

       &nbs= p;      Recently I read from an article that signalling path of SIP is different = from the path of media. When two end points want to communicate using SIP, = the signalling takes place according to the operation of SIP, but once the signalling is over and when the media channel has to be established, = which protocol is used to find the optimal media path?

 

       &nbs= p;     Moreover, when the session has to be terminated, SIP enabled end point has to send = the BYE request, in this case, whether it takes the same path of INVITE request(which initiated the session) or  a different one. I am = considering the stateless proxies to be in the network.

 

with regards

Raj.

 

Everyone is raving about the all-new Yahoo! Mail beta.

------=_NextPart_000_002C_01C7139C.67E698A0-- --===============1111943414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1111943414==-- From sip-bounces@ietf.org Wed Nov 29 13:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUCT-0007Ly-0j; Wed, 29 Nov 2006 13:30:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUCR-0007Lq-UQ for sip@ietf.org; Wed, 29 Nov 2006 13:30:27 -0500 Received: from hu-out-0506.google.com ([72.14.214.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpUCQ-0005wk-De for sip@ietf.org; Wed, 29 Nov 2006 13:30:27 -0500 Received: by hu-out-0506.google.com with SMTP id 38so3503499huc for ; Wed, 29 Nov 2006 10:30:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JvXJfcr0cbZo0xfXkRfTPLeBRFQK4MhLV2TlbO6hkVYlrcJlFAsXBUQNdS+CGUPhPyKSNbDmkTU7xVhVBYXj2gnONNINFYCl9wY4DYgFduw5axXl+CyXB3MEF9GxdqxkSpMCyKjXbrzP5o7ZK6JU11Ekt2b5JEOTeUpDN7LfuAQ= Received: by 10.78.201.15 with SMTP id y15mr2557297huf.1164825024681; Wed, 29 Nov 2006 10:30:24 -0800 (PST) Received: by 10.78.120.15 with HTTP; Wed, 29 Nov 2006 10:30:24 -0800 (PST) Message-ID: <953beacc0611291030r7b072b6mecfabb28a24245ec@mail.gmail.com> Date: Wed, 29 Nov 2006 10:30:24 -0800 From: "Rohan Mahy" To: "Erkki.Koivusalo@nokia.com" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F030E72FD@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <804ffa1de29eb4a2cdad53babb02860c@ekabal.com> <8B1D53AEF7B03449A6D3771B3B7F850F030E72FD@esebe103.NOE.Nokia.com> X-Spam-Score: 2.3 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, Clearly you are suggesting that we make CRLF mandatory to implement for TCP. There would be no longer any need to do STUN over TCP and therefore no need implement code to deal with stream-based demuxing. The text about sigcomp over TCP and STUN over TLS over TCP could also go away. To clarify are you suggesting that an edge proxy can implement outbound without support for UDP flow tokens, without support for STUN keepalives over UDP, both, or neither? thanks, -rohan On 11/29/06, Erkki.Koivusalo@nokia.com wrote: > > Hi, > > >about STUN keepalive usage and discovery, since double CRLF is fully > >backwards compatible with even RFC 2543 implementations. I am > >bringing this up on the list because I hope the WG can look back on > >this and not make the mistake of snowballing complexity to preserve > >UDP parity again in the future. > > Rohan is making a valid point here and I believe in Outbound there > is still room for change to cater for CRLF keepalives as an option > to STUN keepalives over TCP. > > I am calling the WG to look back on the keepalive decision made > earlier for TCP and proposing that Outbound should also cover > CRLF keepalive option. > > Reasons for this proposal: > > >The problem I see is that we have two separate communities using the > >outbound draft: > > > >1) folks that want to get through NATs and Firewalls in the public > >Internet at large - they want to use TCP and TLS with double CRLF for > >keepalives. One "flow" is always one connection. The milestone for > >this would read "Make TCP and TLS work in the Internet". > > I agree with the intents of this community. However this is not what > the current Outbound provides. Outbound specifies two options for > keepalives for reliable connections: TCP keepalive and STUN. > > These options were agreed in IETF 65, a cite from the minutes: > > Proposal: > Do STUN for TCP and UDP > Do CRLF for TCP and STUN for UDP > TCP KeepAlive if supported, 1 or 2 otherwise > > Resolutions: > OS TCP KeepAlive should be used if the client supports it. > Need something more because OS TCP KeepAlive is not supported in > every > client OS. > Consensus to use STUN for UDP > Consensus to use STUN for TCP, with use of OS TCP keep alive above. > > In that meeting the basic assumption was that every Outbound > compliant client should implement both UDP and TCP even if that > is not explicitely mentioned in the draft. However latest -06 > version now makes that debatable by stating: > > Use of outbound with UDP flows typically prevents messages larger > than 1300 bytes from being delivered using TCP as described in > Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP > flows in environments where requests are expected to be larger than > this size is therefore NOT RECOMMENDED. > > In practice this seems to justify implementing "TCP only" UAs > what comes to the Outbound support. In that case the basic assumption > with STUN keepalive (implement it for TCP as it is anyway needed for > UDP as well) would become obsolete. For implementations which can > not use TCP keepalive, CRLF would obviously provide a great benefit > without significant increase of complexity to Outbound. > > > P.S. Last week I made a proposal for "stripped Outbound" without > UDP, STUN keepalives and multiple registrations. As that proposal > did not receive any comments, I decided to propose this minimal > addition to Outbound as an alternative that might be a bit easier > to accept but still achieve some of the benefits. > > Regards, > > Erkki > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 13:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUJu-00058w-A8; Wed, 29 Nov 2006 13:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUJt-00057I-7T for sip@ietf.org; Wed, 29 Nov 2006 13:38:09 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpUJr-000767-UT for sip@ietf.org; Wed, 29 Nov 2006 13:38:09 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kATIUwI16606 for ; Wed, 29 Nov 2006 13:30:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 12:38:01 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E323765@zrc2hxm0.corp.nortel.com> In-Reply-To: <456DAFB1.8070009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccT0CtIC86n/T1ST522wZhTPLmzOwAFDaAQ From: "Francois Audet" To: "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, After re-reading the transcript (especially the points made by Cullen Jennings, Eric Burger and Jon Peterson), and further confirmed by the emailing list discussion, I believe that we should=20 not discuss B2BUA at all and limit it it what happens in the SIP network. This is what I am now proposing. 3.1. Scope of SIPS SIPS means that the SIP resource designated by the target SIPS URI be contacted securily, using TLS, on each SIP hop (last-hop exception=20 nothwistanding). It is outside of the scope of this document to specify=20 what happens when a SIPS URI identifies a UAS resource that "maps" outside of the SIP network, for example, to other networks such as the PSTN. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 13:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUVA-0005Vk-9A; Wed, 29 Nov 2006 13:49:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUV9-0005Vb-Lo for sip@ietf.org; Wed, 29 Nov 2006 13:49:47 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpUV7-0001I7-0R for sip@ietf.org; Wed, 29 Nov 2006 13:49:47 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATInd620107; Wed, 29 Nov 2006 13:49:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 12:49:36 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FEB4547@zrc2hxm2.corp.nortel.com> In-Reply-To: <456DAFB1.8070009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccT0Ctfb59XYLS6RW+13iLFZO+dbQAFSZiw From: "Samir Srivastava" To: "Michael Thomas" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: SIP WG , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mike, Francois personally asked me to make my case separately in another draft. He wanted in his draft the SIPS the way it is etc. Therefore I don't see any value in it at all, as it will not cover why the SIPS is bad for health etc. Why don't we cover this in the next version cipher-suite draft. It will state that it fixes the open holes of SIPS also with the proxy-require of cipher-suite. Thx Samir =20 >-----Original Message----- >From: Michael Thomas [mailto:mat@cisco.com]=20 >Sent: Wednesday, November 29, 2006 8:05 AM >To: Drage, Keith (Keith) >Cc: Srivastava, Samir (SC100:8826); Audet, Francois=20 >(SC100:3055); Jonathan Rosenberg; SIP WG; Dean Willis >Subject: Re: [Sip] Re: SIPS and the PSTN > >This seems very much at cross purposes with Francois' draft=20 >and would just add to the confusion, IMO. What would be better=20 >is for Francois' draft to add that option along with the=20 >documentation (which in itself is like proving a negative, but=20 >I digress) and then have the working group just choose which=20 >section of the draft to delete, or insert what the ultimate=20 >choice was or something like that. I think that documenting=20 >why SIPS was or wasn't deprecated is every bit as important as=20 >clarifying the mistakes that were made initially. > > Mike > > > >Drage, Keith (Keith) wrote: >> (As WG chair) >> >> If you wish the IETF rules allow you to do this. >> >> To make very clear the position: >> >> If you wish to achieve what you want, which is deprecation=20 >of various=20 >> requirements in RFC 3261, then you have already been asked=20 >to provide=20 >> the appropriate discussion material to this internet-draft. Part of=20 >> the output of the internet-draft is to make recommendations on=20 >> improvement, which can include deprecation. But we want to=20 >see the WG=20 >> making an informed decision, based on a clear understanding=20 >of what is=20 >> the impact on existing implementations, why the existing mechanism=20 >> causes damage in the community, and so on. >> >> The scope of the internet-draft is made very clear in the slides >> (http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) -=20 >see slide 2. >> >> Regards >> >> Keith >> >> =20 >>> -----Original Message----- >>> From: Samir Srivastava [mailto:samirsr@nortel.com] >>> Sent: 28 November 2006 23:45 >>> To: Francois Audet; Jonathan Rosenberg >>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >>> Subject: RE: [Sip] Re: SIPS and the PSTN >>> >>> >>> IMHO, after SIPS we are committing one more mistake. After knowing=20 >>> SIPS is completely broken, we are attempting to justify the need on=20 >>> the charter. I am failing to see the value of any these documents.=20 >>> Rather go to IESG directly and get this milestone removed from the=20 >>> charter. All this is merely wastage of cycles. BTW, I don't want to=20 >>> open the complete ranting mode now. >>> >>> Thx >>> Samir >>> >>> =20 >>>> -----Original Message----- >>>> From: Audet, Francois (SC100:3055) >>>> Sent: Tuesday, November 28, 2006 3:23 PM >>>> To: Jonathan Rosenberg >>>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis >>>> Subject: RE: [Sip] Re: SIPS and the PSTN >>>> >>>> Yeah, except that I've been instructed by the Chairs that this >>>> =20 >>> document >>> =20 >>>> is 'informational' only. >>>> >>>> I assume that it means that I can't make normative >>>> =20 >>> statements of any >>> =20 >>>> kind. Is this true? >>>> >>>> =20 >>> =20 >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >> =20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 14:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpV6e-0006ZU-SL; Wed, 29 Nov 2006 14:28:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpV6e-0006YZ-0R for sip@ietf.org; Wed, 29 Nov 2006 14:28:32 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpV6c-0006hM-Hf for sip@ietf.org; Wed, 29 Nov 2006 14:28:31 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATJSR616048 for ; Wed, 29 Nov 2006 14:28:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 13:28:11 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E3238CB@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FEB4547@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccT0Ctfb59XYLS6RW+13iLFZO+dbQAFSZiwAAF5w+A= From: "Francois Audet" To: "Samir Srivastava" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir, I am simply restating what the Chair told you a few times now.=20 Last time was yesterday: http://www1.ietf.org/mail-archive/web/sip/current/msg17544.html You need to clearly make your case, and the the group needs to agree with=20 it before we integrate it in a working group document. > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Wednesday, November 29, 2006 10:50 > To: Michael Thomas; Drage, Keith (Keith) > Cc: Audet, Francois (SC100:3055); Jonathan Rosenberg; SIP WG;=20 > Dean Willis > Subject: RE: [Sip] Re: SIPS and the PSTN >=20 > Hi Mike, >=20 > Francois personally asked me to make my case separately in=20 > another draft. He wanted in his draft the SIPS the way it is etc. >=20 > Therefore I don't see any value in it at all, as it will not=20 > cover why the SIPS is bad for health etc. Why don't we cover=20 > this in the next version cipher-suite draft. It will state=20 > that it fixes the open holes of SIPS also with the=20 > proxy-require of cipher-suite. >=20 > Thx > Samir =20 >=20 > >-----Original Message----- > >From: Michael Thomas [mailto:mat@cisco.com] > >Sent: Wednesday, November 29, 2006 8:05 AM > >To: Drage, Keith (Keith) > >Cc: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055);=20 > >Jonathan Rosenberg; SIP WG; Dean Willis > >Subject: Re: [Sip] Re: SIPS and the PSTN > > > >This seems very much at cross purposes with Francois' draft=20 > and would=20 > >just add to the confusion, IMO. What would be better is for=20 > Francois'=20 > >draft to add that option along with the documentation (which=20 > in itself=20 > >is like proving a negative, but I digress) and then have the working=20 > >group just choose which section of the draft to delete, or=20 > insert what=20 > >the ultimate choice was or something like that. I think that=20 > >documenting why SIPS was or wasn't deprecated is every bit=20 > as important=20 > >as clarifying the mistakes that were made initially. > > > > Mike > > > > > > > >Drage, Keith (Keith) wrote: > >> (As WG chair) > >> > >> If you wish the IETF rules allow you to do this. > >> > >> To make very clear the position: > >> > >> If you wish to achieve what you want, which is deprecation > >of various > >> requirements in RFC 3261, then you have already been asked > >to provide > >> the appropriate discussion material to this=20 > internet-draft. Part of=20 > >> the output of the internet-draft is to make recommendations on=20 > >> improvement, which can include deprecation. But we want to > >see the WG > >> making an informed decision, based on a clear understanding > >of what is > >> the impact on existing implementations, why the existing mechanism=20 > >> causes damage in the community, and so on. > >> > >> The scope of the internet-draft is made very clear in the slides > >> (http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) - > >see slide 2. > >> > >> Regards > >> > >> Keith > >> > >> =20 > >>> -----Original Message----- > >>> From: Samir Srivastava [mailto:samirsr@nortel.com] > >>> Sent: 28 November 2006 23:45 > >>> To: Francois Audet; Jonathan Rosenberg > >>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis > >>> Subject: RE: [Sip] Re: SIPS and the PSTN > >>> > >>> > >>> IMHO, after SIPS we are committing one more mistake.=20 > After knowing=20 > >>> SIPS is completely broken, we are attempting to justify=20 > the need on=20 > >>> the charter. I am failing to see the value of any these documents. > >>> Rather go to IESG directly and get this milestone removed=20 > from the=20 > >>> charter. All this is merely wastage of cycles. BTW, I=20 > don't want to=20 > >>> open the complete ranting mode now. > >>> > >>> Thx > >>> Samir > >>> > >>> =20 > >>>> -----Original Message----- > >>>> From: Audet, Francois (SC100:3055) > >>>> Sent: Tuesday, November 28, 2006 3:23 PM > >>>> To: Jonathan Rosenberg > >>>> Cc: SIP WG; Drage, Keith (Keith); Dean Willis > >>>> Subject: RE: [Sip] Re: SIPS and the PSTN > >>>> > >>>> Yeah, except that I've been instructed by the Chairs that this > >>>> =20 > >>> document > >>> =20 > >>>> is 'informational' only. > >>>> > >>>> I assume that it means that I can't make normative > >>>> =20 > >>> statements of any > >>> =20 > >>>> kind. Is this true? > >>>> > >>>> =20 > >>> =20 > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> =20 > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 14:33:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVB0-0008Mq-0b; Wed, 29 Nov 2006 14:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVAy-0008KS-GP for sip@ietf.org; Wed, 29 Nov 2006 14:33:00 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVAx-0007AJ-02 for sip@ietf.org; Wed, 29 Nov 2006 14:33:00 -0500 Received: from [10.10.19.185] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kATIaqZk029759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Nov 2006 12:36:52 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E2C9986@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E2C9986@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 13:32:45 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: SIP WG , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One possibility is to consider this doc as a BCP, not Info, and BCP can quite reasonably use 2119 language. This is an AD call. It might also be reasonable to use 2119 language in an Informational document. We frequently do this in the case of requirements documents. Where 2119 language is used in an informational document, we have to be clear about why we're using it. For example, "in order to preserve the intent of sips: as discussed in RFC 3261, any proxy or proxy-like device MUST use TLS and a sips: request URI when relaying a request received with a sips: request URI. Failure to do so would . . . " Here you're not talking about protocol specification, but operational requirements needed to meet a protocol specification. -- dean On Nov 28, 2006, at 5:23 PM, Francois Audet wrote: > Yeah, except that I've been instructed by the Chairs that this > document > is 'informational' only. > > I assume that it means that I can't make normative statements of any > kind. Is this true? > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Tuesday, November 28, 2006 14:31 >> To: Audet, Francois (SC100:3055) >> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; >> Dean Willis >> Subject: Re: [Sip] Re: SIPS and the PSTN >> >> Making the must capital in the second paragraph, sounds good to me. >> >> -Jonathan R. >> >> Francois Audet wrote: >> >>> What about this: >>> >>> >>> 3.1. Scope of SIPS >>> >>> It is outside of the scope of this document to specify >> what happens >>> when a SIPS URI identifies a UAS that "maps" outside of the SIP >>> network. For example, to other networks such as the >> PSTN or an H.323 >>> network. These networks have their own standards on what is >>> appropriate security level >>> >>> If a B2BUA is used in lieu of a proxy (as is common in practical >>> deployment), >>> if it receives a request destined to a SIPS Request-URI >> that does >>> not identify itself >>> and it forwards it on towards that Request-URI, it must use a >>> SIPS Request-URI on the outgoing connection as well. >>> >>> >>> >>>> -----Original Message----- >>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>> Sent: Tuesday, November 28, 2006 13:43 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean >>>> Willis >>>> Subject: Re: [Sip] Re: SIPS and the PSTN >>>> >>>> I must say I'm a bit worried about 'should'. I think Dean >> raised this >>>> point; since tons of "proxies" todays are also b2bua's in >> some sense >>>> (that is, they do things a pure proxy cannot), this may very well >>>> reduce the overall effectiveness of sips to just SHOULD use >> TLS. That >>>> seems ever looser than what we have today. >>>> >>>> I'd rather not try to define what constitutes a b2bua that can >>>> downgrade sips, and what kind of b2bua cannot. Instead, it seems >>>> easier to simply state that if you are not the target of >> the sips URI, >>>> and you have a SIP next-hop, you MUST use TLS on that hop. >>>> >>>> -Jonathan R. >>>> >>>> Francois Audet wrote: >>>> >>>> >>>>> Agreed, that's why it's a should, and that's why that section is >>>>> short... >>>>> >>>>> Are we OK with the wording? >>>>> >>>>> And remember: concrete proposals... >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Tuesday, November 28, 2006 08:42 >>>>>> To: Audet, Francois (SC100:3055) >>>>>> Cc: Dean Willis; Joel M. Halpern; SIP WG >>>>>> Subject: Re: [Sip] Re: SIPS and the PSTN >>>>>> >>>>>> I think I am ok with SHOULD for B2BUAs, but I still think >>>> >>>> it is hard >>>> >>>>>> to be specific because of the wide variety of things that >>>> >>>> B2BUAs can >>>> >>>>>> do. >>>>>> >>>>>> Consider a different kind of B2BUA - a conference focus. If >>>> >>>> it allows >>>> >>>>>> connections via SIPS, should it require all connections >> to be SIPS? >>>>>> While that might be a policy for some conferences, I don't >>>> >>>> think it is >>>> >>>>>> the only reasonable policy. >>>>>> >>>>>> Paul >>>>>> >>>>>> Francois Audet wrote: >>>>>> >>>>>> >>>>>>> Let's try to write up something for the document. >>>>>>> I am pretty sure that I remember that in essence, what we >>>>>> >>>>>> decided was >>>>>> >>>>>> >>>>>>> that: >>>>>>> 1) Anything outside SIP network is out-of-scope >>>>>>> 2) B2BUA SHOULD preserve SIPS on both sides. (It was also >>>> >>>> said that >>>> >>>>>>> there ain't nothing we >>>>>>> can do to enforce it of course). >>>>>>> >>>>>>> Here is a strawman: >>>>>>> >>>>>>> 3.1. Scope of SIPS >>>>>>> >>>>>>> It is outside of the scope of this document to specify >>>>>> >>>>>> what happens >>>>>> >>>>>> >>>>>>> when a SIPS URI defines a UAS that "maps" outside of the >>>>>> >>>>>> SIP network. >>>>>> >>>>>> >>>>>>> For example, to other networks such as the PSTN or an >>>>>> >>>>>> H.323 network. >>>>>> >>>>>> >>>>>>> These networks have their own standards on what is >> appropriate >>>>>>> security levels. >>>>>>> >>>>>>> Derived connections in SIP however should use SIPS >>>>>> >>>>>> end-to-end, even >>>>>> >>>>>> >>>>>>> accross distinct SIP networks. For example, If a >>>>>> >>>>>> Back-to-Back-User- >>>>>> >>>>>> >>>>>>> Agent (B2BUA) receives a request destined to a SIPS >>>>>> >>>>>> Request-URI and >>>>>> >>>>>> >>>>>>> it forwards it, it should use a SIPS Request-URI on >> the outgoing >>>>>>> connection as well. This could happen for example when >>>>>> >>>>>> the B2BUA is >>>>>> >>>>>> >>>>>>> Session Border Controller sitting between two SIP >>>>>> >>>>>> networks. It could >>>>>> >>>>>> >>>>>>> also happen in an Application Server or with SIP >>>> >>>> third-party call >>>> >>>>>>> control [RFC3725]. >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> -- >>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) >>>> 952-5050 >>>> http://www.jdrosen.net PHONE: (973) >>>> 952-5000 >>>> http://www.cisco.com >>>> >>> >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 14:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVQu-00060J-MD; Wed, 29 Nov 2006 14:49:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVQt-000604-8X for sip@ietf.org; Wed, 29 Nov 2006 14:49:27 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVQr-0001Of-UN for sip@ietf.org; Wed, 29 Nov 2006 14:49:27 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATJnM620402 for ; Wed, 29 Nov 2006 14:49:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 13:49:22 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FEB46A0@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E3238CB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccT0Ctfb59XYLS6RW+13iLFZO+dbQAFSZiwAAF5w+AAAQnlkA== From: "Samir Srivastava" To: "Francois Audet" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, >From the same link, I am including the message "If you wish to achieve what you want, which is deprecation of various requirements in RFC 3261, then you have already been asked to provide the appropriate discussion material to **this internet-draft**." What this draft means ? Yours Correct. And you yourself is asking to me make my case separately here. I am lost where the glory of SIPS will be documented. Thx Samir >-----Original Message----- >From: Audet, Francois (SC100:3055)=20 >Sent: Wednesday, November 29, 2006 11:28 AM >To: Srivastava, Samir (SC100:8826); 'Drage, Keith (Keith)' >Cc: 'SIP WG' >Subject: RE: [Sip] Re: SIPS and the PSTN > >Samir, > >I am simply restating what the Chair told you a few times now.=20 >Last time was yesterday: >http://www1.ietf.org/mail-archive/web/sip/current/msg17544.html > >You need to clearly make your case, and the the group needs to=20 >agree with it before we integrate it in a working group document. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 15:23:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVwd-0000Vz-72; Wed, 29 Nov 2006 15:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVwb-0000Vp-JZ for sip@ietf.org; Wed, 29 Nov 2006 15:22:13 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVwY-0005go-5L for sip@ietf.org; Wed, 29 Nov 2006 15:22:13 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATKLte22591; Wed, 29 Nov 2006 15:21:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 14:21:53 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E323A08@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccT7TYFhQIz8BCHR2OY6l7nrLJqigAAKtRg From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: SIP WG , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm fine either way (i.e., Info with lenghty explanation, or BCP).=20 I prefer the BCP approach personally, but I'm OK either way. What I don't like is the just changing upppercase to lowercase.... For now I guess I'll just assume Info with lenghty explanation. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, November 29, 2006 11:33 > To: Audet, Francois (SC100:3055) > Cc: Jonathan Rosenberg; SIP WG; Drage, Keith (Keith) > Subject: Re: [Sip] Re: SIPS and the PSTN >=20 >=20 >=20 > One possibility is to consider this doc as a BCP, not Info,=20 > and BCP can quite reasonably use 2119 language. This is an AD call. >=20 > It might also be reasonable to use 2119 language in an=20 > Informational document. We frequently do this in the case of=20 > requirements documents. >=20 > Where 2119 language is used in an informational document, we=20 > have to be clear about why we're using it. For example, "in=20 > order to preserve the intent of sips: as discussed in RFC=20 > 3261, any proxy or proxy-like device MUST use TLS and a sips:=20 > request URI when relaying a request received with a sips:=20 > request URI. Failure to do so would . . . " >=20 > Here you're not talking about protocol specification, but=20 > operational requirements needed to meet a protocol specification. >=20 > -- > dean >=20 > On Nov 28, 2006, at 5:23 PM, Francois Audet wrote: >=20 > > Yeah, except that I've been instructed by the Chairs that this=20 > > document is 'informational' only. > > > > I assume that it means that I can't make normative=20 > statements of any=20 > > kind. Is this true? > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Tuesday, November 28, 2006 14:31 > >> To: Audet, Francois (SC100:3055) > >> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean=20 > >> Willis > >> Subject: Re: [Sip] Re: SIPS and the PSTN > >> > >> Making the must capital in the second paragraph, sounds good to me. > >> > >> -Jonathan R. > >> > >> Francois Audet wrote: > >> > >>> What about this: > >>> > >>> > >>> 3.1. Scope of SIPS > >>> > >>> It is outside of the scope of this document to specify > >> what happens > >>> when a SIPS URI identifies a UAS that "maps" outside of the SIP > >>> network. For example, to other networks such as the > >> PSTN or an H.323 > >>> network. These networks have their own standards on what is > >>> appropriate security level > >>> > >>> If a B2BUA is used in lieu of a proxy (as is common in=20 > practical=20 > >>> deployment), > >>> if it receives a request destined to a SIPS Request-URI > >> that does > >>> not identify itself > >>> and it forwards it on towards that Request-URI, it must use a > >>> SIPS Request-URI on the outgoing connection as well. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>>> Sent: Tuesday, November 28, 2006 13:43 > >>>> To: Audet, Francois (SC100:3055) > >>>> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean=20 > >>>> Willis > >>>> Subject: Re: [Sip] Re: SIPS and the PSTN > >>>> > >>>> I must say I'm a bit worried about 'should'. I think Dean > >> raised this > >>>> point; since tons of "proxies" todays are also b2bua's in > >> some sense > >>>> (that is, they do things a pure proxy cannot), this may=20 > very well=20 > >>>> reduce the overall effectiveness of sips to just SHOULD use > >> TLS. That > >>>> seems ever looser than what we have today. > >>>> > >>>> I'd rather not try to define what constitutes a b2bua that can=20 > >>>> downgrade sips, and what kind of b2bua cannot. Instead, it seems=20 > >>>> easier to simply state that if you are not the target of > >> the sips URI, > >>>> and you have a SIP next-hop, you MUST use TLS on that hop. > >>>> > >>>> -Jonathan R. > >>>> > >>>> Francois Audet wrote: > >>>> > >>>> > >>>>> Agreed, that's why it's a should, and that's why that=20 > section is=20 > >>>>> short... > >>>>> > >>>>> Are we OK with the wording? > >>>>> > >>>>> And remember: concrete proposals... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: Tuesday, November 28, 2006 08:42 > >>>>>> To: Audet, Francois (SC100:3055) > >>>>>> Cc: Dean Willis; Joel M. Halpern; SIP WG > >>>>>> Subject: Re: [Sip] Re: SIPS and the PSTN > >>>>>> > >>>>>> I think I am ok with SHOULD for B2BUAs, but I still think > >>>> > >>>> it is hard > >>>> > >>>>>> to be specific because of the wide variety of things that > >>>> > >>>> B2BUAs can > >>>> > >>>>>> do. > >>>>>> > >>>>>> Consider a different kind of B2BUA - a conference focus. If > >>>> > >>>> it allows > >>>> > >>>>>> connections via SIPS, should it require all connections > >> to be SIPS? > >>>>>> While that might be a policy for some conferences, I don't > >>>> > >>>> think it is > >>>> > >>>>>> the only reasonable policy. > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>> Francois Audet wrote: > >>>>>> > >>>>>> > >>>>>>> Let's try to write up something for the document. > >>>>>>> I am pretty sure that I remember that in essence, what we > >>>>>> > >>>>>> decided was > >>>>>> > >>>>>> > >>>>>>> that: > >>>>>>> 1) Anything outside SIP network is out-of-scope > >>>>>>> 2) B2BUA SHOULD preserve SIPS on both sides. (It was also > >>>> > >>>> said that > >>>> > >>>>>>> there ain't nothing we > >>>>>>> can do to enforce it of course). > >>>>>>> > >>>>>>> Here is a strawman: > >>>>>>> > >>>>>>> 3.1. Scope of SIPS > >>>>>>> > >>>>>>> It is outside of the scope of this document to specify > >>>>>> > >>>>>> what happens > >>>>>> > >>>>>> > >>>>>>> when a SIPS URI defines a UAS that "maps" outside of the > >>>>>> > >>>>>> SIP network. > >>>>>> > >>>>>> > >>>>>>> For example, to other networks such as the PSTN or an > >>>>>> > >>>>>> H.323 network. > >>>>>> > >>>>>> > >>>>>>> These networks have their own standards on what is > >> appropriate > >>>>>>> security levels. > >>>>>>> > >>>>>>> Derived connections in SIP however should use SIPS > >>>>>> > >>>>>> end-to-end, even > >>>>>> > >>>>>> > >>>>>>> accross distinct SIP networks. For example, If a > >>>>>> > >>>>>> Back-to-Back-User- > >>>>>> > >>>>>> > >>>>>>> Agent (B2BUA) receives a request destined to a SIPS > >>>>>> > >>>>>> Request-URI and > >>>>>> > >>>>>> > >>>>>>> it forwards it, it should use a SIPS Request-URI on > >> the outgoing > >>>>>>> connection as well. This could happen for example when > >>>>>> > >>>>>> the B2BUA is > >>>>>> > >>>>>> > >>>>>>> Session Border Controller sitting between two SIP > >>>>>> > >>>>>> networks. It could > >>>>>> > >>>>>> > >>>>>>> also happen in an Application Server or with SIP > >>>> > >>>> third-party call > >>>> > >>>>>>> control [RFC3725]. > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>>> sipping@ietf.org for new developments on the application of sip > >>>>> > >>>> > >>>> --=20 > >>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>>> Cisco Fellow Parsippany, NJ > >>>> 07054-2711 > >>>> Cisco Systems > >>>> jdrosen@cisco.com FAX: (973) =20 > >>>> 952-5050 > >>>> http://www.jdrosen.net PHONE: (973) =20 > >>>> 952-5000 > >>>> http://www.cisco.com > >>>> > >>> > >>> > >> > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 15:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpW01-0001ft-24; Wed, 29 Nov 2006 15:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpVzz-0001fi-Rh for sip@ietf.org; Wed, 29 Nov 2006 15:25:43 -0500 Received: from i3smtp.inin.com ([209.43.1.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpVzn-0006J1-6B for sip@ietf.org; Wed, 29 Nov 2006 15:25:43 -0500 X-SEF-Processed: 5_0_0_910__2006_11_29_15_25_28 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp.inin.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Nov 2006 15:25:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 15:25:28 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B339039B9F2F@i3mail1.i3domain.inin.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FEB46A0@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN thread-index: AccT0Ctfb59XYLS6RW+13iLFZO+dbQAFSZiwAAF5w+AAAQnlkAABAtQA From: "Snyder, Duke" To: "Samir Srivastava" , "Francois Audet" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some want sips to mean "use TLS end to end" (and I don't think "end" has been defined, as in the case of a SIP/PSTN gateway). I think what is really needed is a mechanism to request some minimal level of security for the signalling and the payload. If sips=3DTLS, what would stop a = SBC from using TLS/SRTP on one side and TLS/RTP on the other, sending the audio of the call un-encrypted? The 'whole' call is not very secure, which probably was the original intent of sips. Also, TLS is not the only mechanism to secure the signaling. Is TCP over a VPN secure? Is UDP over a protected LAN to a protected phone in a protected room secure? Don't count out the devices on the network that have other ways to secure a call. =20 I think saying "sips"=3D"TLS end to end" is not a good idea. -----Original Message----- From: Samir Srivastava [mailto:samirsr@nortel.com]=20 Sent: Wednesday, November 29, 2006 2:49 PM To: Francois Audet; Drage, Keith (Keith) Cc: SIP WG Subject: RE: [Sip] Re: SIPS and the PSTN Francois, >From the same link, I am including the message "If you wish to achieve what you want, which is deprecation of various requirements in RFC 3261, then you have already been asked to provide the appropriate discussion material to **this internet-draft**." What this draft means ? Yours Correct. And you yourself is asking to me make my case separately here. I am lost where the glory of SIPS will be documented. Thx Samir >-----Original Message----- >From: Audet, Francois (SC100:3055) >Sent: Wednesday, November 29, 2006 11:28 AM >To: Srivastava, Samir (SC100:8826); 'Drage, Keith (Keith)' >Cc: 'SIP WG' >Subject: RE: [Sip] Re: SIPS and the PSTN > >Samir, > >I am simply restating what the Chair told you a few times now. >Last time was yesterday: >http://www1.ietf.org/mail-archive/web/sip/current/msg17544.html > >You need to clearly make your case, and the the group needs to >agree with it before we integrate it in a working group document. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 18:23:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpYjU-000242-1l; Wed, 29 Nov 2006 18:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpYjR-0001pD-Ou for sip@ietf.org; Wed, 29 Nov 2006 18:20:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpYjP-0006OQ-2w for sip@ietf.org; Wed, 29 Nov 2006 18:20:49 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 15:20:46 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kATNKjD5024505 for ; Wed, 29 Nov 2006 18:20:45 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kATNKjDM024402 for ; Wed, 29 Nov 2006 18:20:45 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 18:20:45 -0500 Received: from [161.44.79.221] ([161.44.79.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 18:20:45 -0500 Message-ID: <456E15CD.60805@cisco.com> Date: Wed, 29 Nov 2006 18:20:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2006 23:20:45.0516 (UTC) FILETIME=[FF1640C0:01C7140C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5725; t=1164842445; x=1165706445; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20 |To:=20SIP=20IETF=20; bh=NtnmxUfUE2Zz9KkDBYT45YdjDtwiFHfX3iAJJnOCaMU=; b=brBmg7QIxwBNwupe36wiPhx0P5MZnyFM1gTRLSb/wG0L2h6lrPWznNIDFLUZwoh25VRBp2di q6ZSgK069O8miue33wKLstIau2RlWZqaga/eqCzmVJPLBCDVhQFzwRmQ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [Sip] Issue: Expiration of temp-gruu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org After some study, I have encountered a potential difficulty in determining when temp-gruus expire. After discussing this with Jonathan we decided to bring it to the list for discussion. As now defined, when you first register you may get a temp-gruu, which will remain valid as long as the registration does not expire or be removed. (Removal is a special case of expiration.) Each time the UA refreshes the registration it may get a new temp-gruu which also remains valid for the life of the registration. The UA can accumulate all these temp-gruus and use them as it sees fit until they expire. The problem is: how does the UA know when the registration has ended and the temp-gruus associated with it rendered invalid? This seems like a simple question, and in some cases it is simple, but not in all cases. The following are at least some of the ways that the registration can be ended, causing the invalidation of temp-gruus: 1) the UA that originally registered may explicitly deregister 2) the UA the originally registered may simply permit the registration to expire without attempting to refresh it 3) the UA may attempt to refresh the registration, but be too slow, so that the reregistration arrives after the prior one expires 4) some other UA may deregister all the registrations, including the one by this UA. (When the UA decides it should refresh the registration it will actually create a new one.) 5) the registrar may remove the registration administratively 6) the registrar may crash and restart, losing all its registrations In each of these cases the previously assigned temp-gruus become invalid. If the UA continues to use them, bad things will happen. This is true both for calls that are active when the deregistration occurs, and calls that are established later. What kinds of bad things happen? - requests addressed to the gruu, both in-dialog and out-of-dialog will be undeliverable. (For instance a reINVITE or BYE in an existing call, or an out-of-dialog INVITE/Replaces for a transfer.) - request originated by the UA using the invalid gruu will fail immediately because the gruu is invalid. - if the UA subsequently reregisters, receives an incoming call, and uses one of the old temp-gruus as its contact, then the call will be established, but subsequent in- and out-of-dialog requests to the contact will fail. So clearly it is important for the UA to stop using temp-gruus that have become invalid. How can it know to do that in all of the above cases? 1) is straightforward. The UA knows it is deregistering, and should discard any cached temp-gruus. If it has a dialog with one of the temp-gruus as a contact, then it should do a target refresh and supply some working contact. (It really should do this *before* deregistering, and for a pub-gruu as well.) 2) the UA should take all the actions mentioned for (1) at or before the expiration time. This should be done a bit early to guard against clock skew problems. 3) in this case, it may be impossible for the UA to know whether the REGISTER arrived in time to be a reREGISTER or if it arrived late and was treated as a new REGISTER after the expiration of the old one. (The response to the REGISTER includes nothing that distinguishes the two cases.) About the best that can be done in this case is to check the time at which the response to the REGISTER is received. If it falls after the expected expiration time for the registration, act as if the old registration had expired. 4) This is a major problem. Of course, regardless of GRUU, the UA won't be able to receive incoming calls until it decides it is time to refresh the registration. In addition, until the registration reestablished, calls originated with one of its existing gruus will fail. Once the registration is reestablished, it still won't know its old temp-gruus are invalid. The only remedy for this is to subscribe to the "reg" event package, and use the resulting notifications to identify when it has been unregistered. If it does that, it can invalidate all its old temp-gruus, and then presumably reregister. 5) this is functionally equivalent to (4), except that perhaps attempts to reregister may fail. 6) this is also functionally equivalent to (4). The "reg" event does provide a fairly complete solution to this problem, for those that are willing and able to use it. It is not however a 100% reliable solution. Consider case (3), where the UA has a reg event subscription. All is well if the registration expires and a notification is sent indicating that, and then the reregistration occurs and a notification is sent about that. But if they happen very closely in time, it may be that only one notification is sent, reflecting the result of the reregistration. In that case the UA will not be aware that it had been unregistered for a period of time. A *complete* solution would, IMO, involve changing REGISTER so that it returns an indication of whether this was a new registration, or a refresh. This could take many forms. For instance the timestamp of the initial registration could always be returned with each contact, as well as the expiration time. The big question is whether this is a big enough issue to require a solution now, as part of GRUU, or if it can be ignored as insignificant or postponed to future work. I'd appreciate hearing what others think about this. At the moment I am leaning toward doing nothing, at least for now. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Nov 29 20:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaV7-0003bQ-VX; Wed, 29 Nov 2006 20:14:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaUd-0002Rc-W0 for sip@ietf.org; Wed, 29 Nov 2006 20:13:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpaPg-00073F-9q for sip@ietf.org; Wed, 29 Nov 2006 20:08:38 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 17:08:32 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAU18Vu6028375; Wed, 29 Nov 2006 17:08:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAU18LOV024219; Wed, 29 Nov 2006 17:08:21 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 17:08:21 -0800 Received: from [64.101.36.185] ([64.101.36.185]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 17:08:20 -0800 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF0E2C9986@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1047B7BE-BBA1-4AA5-BACD-A2F59D3E43A8@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: SIPS and the PSTN Date: Wed, 29 Nov 2006 17:08:33 -0800 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Nov 2006 01:08:20.0680 (UTC) FILETIME=[06AA1C80:01C7141C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8361; t=1164848911; x=1165712911; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIPS=20and=20the=20PSTN |Sender:=20; bh=ovEZiCgTkH0hL8RbW8WLpsz2xs5uQx/jiwrHwBi15Dw=; b=SqApmLsOsDkHh8ELA8e8hyPnH1C2JyiY4GmzaHa2sJg204A1K6hab19VDefHQOuDL6LtSBX2 GSR0M3FoeSHcloCQdWtYRLv5BOpdIF098VSiYzeUz2dZu4tfRTaZ35D4; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: SIP WG , Francois Audet , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With my AD hat on ... Let's figure out what this document needs to say, including normative language. Once we have that it will be easy to figure out if it is INFO, BCP, or a PS that updates 3261. Cullen On Nov 29, 2006, at 11:32 AM, Dean Willis wrote: > > > One possibility is to consider this doc as a BCP, not Info, and BCP > can quite reasonably use 2119 language. This is an AD call. > > It might also be reasonable to use 2119 language in an > Informational document. We frequently do this in the case of > requirements documents. > > Where 2119 language is used in an informational document, we have > to be clear about why we're using it. For example, "in order to > preserve the intent of sips: as discussed in RFC 3261, any proxy or > proxy-like device MUST use TLS and a sips: request URI when > relaying a request received with a sips: request URI. Failure to do > so would . . . " > > Here you're not talking about protocol specification, but > operational requirements needed to meet a protocol specification. > > -- > dean > > On Nov 28, 2006, at 5:23 PM, Francois Audet wrote: > >> Yeah, except that I've been instructed by the Chairs that this >> document >> is 'informational' only. >> >> I assume that it means that I can't make normative statements of any >> kind. Is this true? >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>> Sent: Tuesday, November 28, 2006 14:31 >>> To: Audet, Francois (SC100:3055) >>> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; >>> Dean Willis >>> Subject: Re: [Sip] Re: SIPS and the PSTN >>> >>> Making the must capital in the second paragraph, sounds good to me. >>> >>> -Jonathan R. >>> >>> Francois Audet wrote: >>> >>>> What about this: >>>> >>>> >>>> 3.1. Scope of SIPS >>>> >>>> It is outside of the scope of this document to specify >>> what happens >>>> when a SIPS URI identifies a UAS that "maps" outside of the SIP >>>> network. For example, to other networks such as the >>> PSTN or an H.323 >>>> network. These networks have their own standards on what is >>>> appropriate security level >>>> >>>> If a B2BUA is used in lieu of a proxy (as is common in practical >>>> deployment), >>>> if it receives a request destined to a SIPS Request-URI >>> that does >>>> not identify itself >>>> and it forwards it on towards that Request-URI, it must use a >>>> SIPS Request-URI on the outgoing connection as well. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>>> Sent: Tuesday, November 28, 2006 13:43 >>>>> To: Audet, Francois (SC100:3055) >>>>> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean >>>>> Willis >>>>> Subject: Re: [Sip] Re: SIPS and the PSTN >>>>> >>>>> I must say I'm a bit worried about 'should'. I think Dean >>> raised this >>>>> point; since tons of "proxies" todays are also b2bua's in >>> some sense >>>>> (that is, they do things a pure proxy cannot), this may very well >>>>> reduce the overall effectiveness of sips to just SHOULD use >>> TLS. That >>>>> seems ever looser than what we have today. >>>>> >>>>> I'd rather not try to define what constitutes a b2bua that can >>>>> downgrade sips, and what kind of b2bua cannot. Instead, it seems >>>>> easier to simply state that if you are not the target of >>> the sips URI, >>>>> and you have a SIP next-hop, you MUST use TLS on that hop. >>>>> >>>>> -Jonathan R. >>>>> >>>>> Francois Audet wrote: >>>>> >>>>> >>>>>> Agreed, that's why it's a should, and that's why that section is >>>>>> short... >>>>>> >>>>>> Are we OK with the wording? >>>>>> >>>>>> And remember: concrete proposals... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> Sent: Tuesday, November 28, 2006 08:42 >>>>>>> To: Audet, Francois (SC100:3055) >>>>>>> Cc: Dean Willis; Joel M. Halpern; SIP WG >>>>>>> Subject: Re: [Sip] Re: SIPS and the PSTN >>>>>>> >>>>>>> I think I am ok with SHOULD for B2BUAs, but I still think >>>>> >>>>> it is hard >>>>> >>>>>>> to be specific because of the wide variety of things that >>>>> >>>>> B2BUAs can >>>>> >>>>>>> do. >>>>>>> >>>>>>> Consider a different kind of B2BUA - a conference focus. If >>>>> >>>>> it allows >>>>> >>>>>>> connections via SIPS, should it require all connections >>> to be SIPS? >>>>>>> While that might be a policy for some conferences, I don't >>>>> >>>>> think it is >>>>> >>>>>>> the only reasonable policy. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Francois Audet wrote: >>>>>>> >>>>>>> >>>>>>>> Let's try to write up something for the document. >>>>>>>> I am pretty sure that I remember that in essence, what we >>>>>>> >>>>>>> decided was >>>>>>> >>>>>>> >>>>>>>> that: >>>>>>>> 1) Anything outside SIP network is out-of-scope >>>>>>>> 2) B2BUA SHOULD preserve SIPS on both sides. (It was also >>>>> >>>>> said that >>>>> >>>>>>>> there ain't nothing we >>>>>>>> can do to enforce it of course). >>>>>>>> >>>>>>>> Here is a strawman: >>>>>>>> >>>>>>>> 3.1. Scope of SIPS >>>>>>>> >>>>>>>> It is outside of the scope of this document to specify >>>>>>> >>>>>>> what happens >>>>>>> >>>>>>> >>>>>>>> when a SIPS URI defines a UAS that "maps" outside of the >>>>>>> >>>>>>> SIP network. >>>>>>> >>>>>>> >>>>>>>> For example, to other networks such as the PSTN or an >>>>>>> >>>>>>> H.323 network. >>>>>>> >>>>>>> >>>>>>>> These networks have their own standards on what is >>> appropriate >>>>>>>> security levels. >>>>>>>> >>>>>>>> Derived connections in SIP however should use SIPS >>>>>>> >>>>>>> end-to-end, even >>>>>>> >>>>>>> >>>>>>>> accross distinct SIP networks. For example, If a >>>>>>> >>>>>>> Back-to-Back-User- >>>>>>> >>>>>>> >>>>>>>> Agent (B2BUA) receives a request destined to a SIPS >>>>>>> >>>>>>> Request-URI and >>>>>>> >>>>>>> >>>>>>>> it forwards it, it should use a SIPS Request-URI on >>> the outgoing >>>>>>>> connection as well. This could happen for example when >>>>>>> >>>>>>> the B2BUA is >>>>>>> >>>>>>> >>>>>>>> Session Border Controller sitting between two SIP >>>>>>> >>>>>>> networks. It could >>>>>>> >>>>>>> >>>>>>>> also happen in an Application Server or with SIP >>>>> >>>>> third-party call >>>>> >>>>>>>> control [RFC3725]. >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>> >>>>> -- >>>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>>> Cisco Fellow Parsippany, NJ >>>>> 07054-2711 >>>>> Cisco Systems >>>>> jdrosen@cisco.com FAX: (973) >>>>> 952-5050 >>>>> http://www.jdrosen.net PHONE: (973) >>>>> 952-5000 >>>>> http://www.cisco.com >>>>> >>>> >>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Cisco Fellow Parsippany, NJ >>> 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 03:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphHW-00022Q-Bs; Thu, 30 Nov 2006 03:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphHU-0001ws-SV for sip@ietf.org; Thu, 30 Nov 2006 03:28:32 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GphHO-0006Ls-0B for sip@ietf.org; Thu, 30 Nov 2006 03:28:32 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D8E92C74; Thu, 30 Nov 2006 09:28:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 09:28:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Date: Thu, 30 Nov 2006 09:28:05 +0100 Message-ID: <7374777208BDC7449D5620EF94232567A940F4@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] strawman text for FASTEST proposal in outbound Thread-Index: AccN0/DhaVfBQAGgTxakDnaeYahaJgAer/UgAV09JCA= From: "Christer Holmberg \(JO/LMF\)" To: "Kevin Johns" , "Rohan Mahy" , "Francois Audet" X-OriginalArrivalTime: 30 Nov 2006 08:28:06.0775 (UTC) FILETIME=[7600B070:01C71459] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I am in favor of FASTEST, however I am not sure the text=20 >being proposed is necessary. How does outbound prohibit the=20 >change to TCP? >=20 >This seems to be an issue of how the algorithm for generating=20 >the flow token is implemented and those in outbound are=20 >informational from my reading. Thus, as long as the edge=20 >proxy utilizes an algorithm which generates a flow token=20 >which resolves to a source IP and Port and Destination IP and=20 >Port the edge proxy would be free to determine which=20 >transport protocol to use. >=20 >If a NAT is present, the UA will need to establish both a UDP=20 >and TCP flow to the edge proxy to allow inbound requests on=20 >either. If a NAT is not present, then the UA need only=20 >establish one flow as the edge proxy can initial the other=20 >flow if needed. How does the UA knows whether there is a NAT or not? How does the edge proxy knows whether there is a NAT or not? Regards, Christer > =20 >=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Tuesday, November 21, 2006 6:15 PM > To: Francois Audet > Cc: SIP WG; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] strawman text for FASTEST proposal in outbound >=20 > Hi Francois, >=20 > On 11/21/06, Francois Audet wrote: > > > > > To make the discussion about the outbound transport issues more=20 > > > concrete, here is some strawman text for the "FASTEST" direction. > > > > > > thanks, > > > -rohan > > > > > > PROPOSED TEXT: > > > Use of outbound with UDP flows prevents messages larger than 1300=20 > > > bytes from being delivered using TCP as described in > > ^^^ > > Shouldn't this say "UDP"? >=20 > No. Outbound using UDP flows prevents the switchover to a=20 > congestion-controlled transport, such as TCP as described in=20 > this quote from RFC 3261: >=20 > If a request is within 200 bytes of the path MTU, or if=20 > it is larger than 1300 bytes and the path MTU is unknown, the=20 > request MUST be sent using an RFC 2914 [36] congestion=20 > controlled transport protocol, such as TCP. If this causes a=20 > change in the transport protocol from the one indicated in=20 > the top Via, the value in the top Via MUST be changed. This=20 > prevents fragmentation of messages over UDP and provides=20 > congestion control for larger messages. >=20 > thanks, > -rohan >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 04:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphwI-0008BC-08; Thu, 30 Nov 2006 04:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphwF-0008B4-M0 for sip@ietf.org; Thu, 30 Nov 2006 04:10:39 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GphwD-00082z-3c for sip@ietf.org; Thu, 30 Nov 2006 04:10:39 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J9J00A4BDHCDJ@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 Nov 2006 09:10:25 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Nov 2006 09:10:17 +0000 Content-return: allowed Date: Thu, 30 Nov 2006 09:10:16 +0000 From: "Elwell, John" Subject: RE: [Sip] Issue: Expiration of temp-gruu To: Paul Kyzivat , SIP IETF Message-id: <50B1CBA96870A34799A506B2313F26670A76AB7A@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess some of my concerns about temporary GRUUs are starting to creep back again. It is a question of how they are used. If a UA gives a temporary GRUU out as a contact on a dialog and expects it to be used only during the lifetime of that dialog, then refreshing the target if the temporary GRUU is lost would get around the problem in most cases. There will of course be race conditions, e.g., the UA sends out a target refresh but the remote UA has already sent a REFER request to the old target. What concerns me more is if there are use cases where a remote UA might want to use a received temporary GRUU long after the dialog has terminated. If the local UA keeps refreshing its subscription correctly and successfully, then the temporary GRUU will remain valid. But if it is lost through circumstances beyond the control of the local UA, then it has no means to inform the remote UA that it is no longer valid and that a different temporary GRUU must be used. One example given in gruu-11 is the use of a GRUU on a web page. If a temporary GRUU were to be used (presumably on a temporary web page), similar considerations would apply. Another concern is if I want to give out a different temporary GRUU to different remote UAs, so that I can easily turn off individual temporary GRUUs if I no longer wish to receive requests from the parties concerned. When I first register I have only one temporary GRUU, so if I want to give out several temporary GRUUs I would need to refresh my subscription several times to obtain these GRUUs. I just have an uneasy feeling that the temporary GRUU mechanism might be somewhat orthogonal to possible use cases, although I am having difficulty articulating particular real life use cases. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 29 November 2006 23:21 > To: SIP IETF > Subject: [Sip] Issue: Expiration of temp-gruu > > After some study, I have encountered a potential difficulty in > determining when temp-gruus expire. After discussing this > with Jonathan > we decided to bring it to the list for discussion. > > As now defined, when you first register you may get a > temp-gruu, which > will remain valid as long as the registration does not expire or be > removed. (Removal is a special case of expiration.) Each time the UA > refreshes the registration it may get a new temp-gruu which > also remains > valid for the life of the registration. The UA can accumulate > all these > temp-gruus and use them as it sees fit until they expire. > > The problem is: how does the UA know when the registration > has ended and > the temp-gruus associated with it rendered invalid? > > This seems like a simple question, and in some cases it is > simple, but > not in all cases. The following are at least some of the ways > that the > registration can be ended, causing the invalidation of temp-gruus: > 1) the UA that originally registered may explicitly deregister > 2) the UA the originally registered may simply permit the > registration to expire without attempting to refresh it > 3) the UA may attempt to refresh the registration, but be too slow, > so that the reregistration arrives after the prior one expires > 4) some other UA may deregister all the registrations, including > the one by this UA. (When the UA decides it should refresh the > registration it will actually create a new one.) > 5) the registrar may remove the registration administratively > 6) the registrar may crash and restart, losing all its registrations > > In each of these cases the previously assigned temp-gruus become > invalid. If the UA continues to use them, bad things will > happen. This > is true both for calls that are active when the > deregistration occurs, > and calls that are established later. What kinds of bad things happen? > - requests addressed to the gruu, both in-dialog and out-of-dialog > will be undeliverable. (For instance a reINVITE or BYE in an > existing call, or an out-of-dialog INVITE/Replaces for a transfer.) > > - request originated by the UA using the invalid gruu will fail > immediately because the gruu is invalid. > > - if the UA subsequently reregisters, receives an incoming call, and > uses one of the old temp-gruus as its contact, then the call will > be established, but subsequent in- and out-of-dialog requests to > the contact will fail. > > So clearly it is important for the UA to stop using > temp-gruus that have > become invalid. How can it know to do that in all of the above cases? > > 1) is straightforward. The UA knows it is deregistering, and should > discard any cached temp-gruus. If it has a dialog with one of the > temp-gruus as a contact, then it should do a target refresh and > supply some working contact. (It really should do this *before* > deregistering, and for a pub-gruu as well.) > > 2) the UA should take all the actions mentioned for (1) at or before > the expiration time. This should be done a bit early to guard > against clock skew problems. > > 3) in this case, it may be impossible for the UA to know whether > the REGISTER arrived in time to be a reREGISTER or if it arrived > late and was treated as a new REGISTER after the expiration of > the old one. (The response to the REGISTER includes nothing that > distinguishes the two cases.) About the best that can be done in > this case is to check the time at which the response to the > REGISTER is received. If it falls after the expected expiration > time for the registration, act as if the old registration had > expired. > > 4) This is a major problem. Of course, regardless of GRUU, the UA > won't be able to receive incoming calls until it decides it is > time to refresh the registration. In addition, until the > registration reestablished, calls originated with one of its > existing gruus will fail. Once the registration is reestablished, > it still won't know its old temp-gruus are invalid. The only > remedy for this is to subscribe to the "reg" event package, > and use the resulting notifications to identify when it has > been unregistered. If it does that, it can invalidate all its > old temp-gruus, and then presumably reregister. > > 5) this is functionally equivalent to (4), except that perhaps > attempts to reregister may fail. > > 6) this is also functionally equivalent to (4). > > The "reg" event does provide a fairly complete solution to > this problem, > for those that are willing and able to use it. It is not > however a 100% > reliable solution. Consider case (3), where the UA has a reg event > subscription. All is well if the registration expires and a > notification > is sent indicating that, and then the reregistration occurs and a > notification is sent about that. But if they happen very closely in > time, it may be that only one notification is sent, reflecting the > result of the reregistration. In that case the UA will not be > aware that > it had been unregistered for a period of time. > > A *complete* solution would, IMO, involve changing REGISTER > so that it > returns an indication of whether this was a new registration, or a > refresh. This could take many forms. For instance the > timestamp of the > initial registration could always be returned with each > contact, as well > as the expiration time. > > The big question is whether this is a big enough issue to require a > solution now, as part of GRUU, or if it can be ignored as > insignificant > or postponed to future work. > > I'd appreciate hearing what others think about this. At the > moment I am > leaning toward doing nothing, at least for now. > > Thanks, > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 04:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gphz3-00040J-Sv; Thu, 30 Nov 2006 04:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gphz2-000408-Qh for sip@ietf.org; Thu, 30 Nov 2006 04:13:32 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gphz1-0000PC-HB for sip@ietf.org; Thu, 30 Nov 2006 04:13:32 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 8DD573BE4B; Thu, 30 Nov 2006 10:13:20 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21589-01-82; Thu, 30 Nov 2006 10:13:20 +0100 (CET) Received: from [192.168.123.17] (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 2C3EB3BE2D; Thu, 30 Nov 2006 10:13:11 +0100 (CET) Message-ID: <456EA08B.6070102@it.su.se> Date: Thu, 30 Nov 2006 10:12:43 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] strawman text for FASTEST proposal in outbound References: <7374777208BDC7449D5620EF94232567A940F4@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567A940F4@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.567 tagged_above=-99 required=7 tests=[AWL=0.098, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Cullen Jennings , Rohan Mahy , Kevin Johns , SIP WG , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: ... > How does the UA knows whether there is a NAT or not? How does the edge > proxy knows whether there is a NAT or not? Also remember that it doesn't have to be a NAT that we have to use Outbound to work around either - it can be a statefull firewall as well. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From atbswase@centene.com Thu Nov 30 05:38:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpjJB-00024u-3w for sip-archive@lists.ietf.org; Thu, 30 Nov 2006 05:38:25 -0500 Received: from [222.131.22.22] (helo=[222.131.22.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpjJ9-0006kO-JI for sip-archive@lists.ietf.org; Thu, 30 Nov 2006 05:38:25 -0500 From: "button." To: sip-archive@lists.ietf.org Subject: re: did you get the raise? Date: Thu, 30 Nov 2006 18:38:12 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C714AE.B071C6E0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccUrrBxI1Y9XbL9TLKMkwux9OQnew== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <3743C63A83BCFF1.470BA90EF5@centene.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ------=_NextPart_000_0005_01C714AE.B071C6E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
BLNM Becomes Primary VOIP Agent For China Telcom and China Netcom!
Huge VOIP Contract gets Signed With Beijing Oriental Inc.

Company: Bralorne Mining Company
Sym: BLNM.OB
Price: $0.27

BLNM.OB is the primary VOIP agent for China's two largest telecoms, China Telcom and China Netcom. This is fast pushing them to become a major player in the worlds fastest growing telecommunications market.

Additionally, they have now signed contract to provide 3GenisIP service to Beijing Oriental which in turn exposes them to over 300 national and international clients of Beijing Oriental.

This company is growing in leaps and bounds. Read over all the news in the last week and grab BLNM first thing Thursday Morning.
------=_NextPart_000_0005_01C714AE.B071C6E0-- From sip-bounces@ietf.org Thu Nov 30 08:00:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GplUt-0006Tf-T7; Thu, 30 Nov 2006 07:58:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GplUr-0006TQ-Px for sip@ietf.org; Thu, 30 Nov 2006 07:58:37 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GplUk-00010z-2O for sip@ietf.org; Thu, 30 Nov 2006 07:58:37 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33E1B4F0001; Thu, 30 Nov 2006 13:58:27 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 13:58:26 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 13:56:50 +0100 Message-ID: <7374777208BDC7449D5620EF94232567ACBA21@esealmw113.eemea.ericsson.se> In-Reply-To: <953beacc0611291030r7b072b6mecfabb28a24245ec@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccT5QIZsMiqTDG9TWuvmiw3PwUElQAmJArg From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , X-OriginalArrivalTime: 30 Nov 2006 12:58:26.0891 (UTC) FILETIME=[39F1F9B0:01C7147F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Why don't we let the edge proxy choose which keep-alive mechanism to use? The outbound spec should now say (I haven't had time to check, but I hope me and Rohan agreed to add it :) that the edge proxy can insert the keepalive parameter in the Path header. So, we define a "CRLF" value for the parameter, and the edge proxy can then use that value for TCP flows. Of course, if the UA is not mandated to implement all kind of keep-alives, it will also have to be able to indicate to the edge proxy which keep-alive mechanisms it support. Regards, Christer =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: 29. marraskuuta 2006 20:30 > To: Erkki.Koivusalo@nokia.com > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Hi Erkki, >=20 > Clearly you are suggesting that we make CRLF mandatory to=20 > implement for TCP. There would be no longer any need to do=20 > STUN over TCP and therefore no need implement code to deal=20 > with stream-based demuxing. > The text about sigcomp over TCP and STUN over TLS over TCP=20 > could also go away. >=20 > To clarify are you suggesting that an edge proxy can=20 > implement outbound without support for UDP flow tokens,=20 > without support for STUN keepalives over UDP, both, or neither? >=20 > thanks, > -rohan >=20 > On 11/29/06, Erkki.Koivusalo@nokia.com=20 > wrote: > > > > Hi, > > > > >about STUN keepalive usage and discovery, since double=20 > CRLF is fully=20 > > >backwards compatible with even RFC 2543 implementations. I am=20 > > >bringing this up on the list because I hope the WG can=20 > look back on=20 > > >this and not make the mistake of snowballing complexity to=20 > preserve=20 > > >UDP parity again in the future. > > > > Rohan is making a valid point here and I believe in=20 > Outbound there is=20 > > still room for change to cater for CRLF keepalives as an option to=20 > > STUN keepalives over TCP. > > > > I am calling the WG to look back on the keepalive decision made=20 > > earlier for TCP and proposing that Outbound should also cover CRLF=20 > > keepalive option. > > > > Reasons for this proposal: > > > > >The problem I see is that we have two separate communities=20 > using the=20 > > >outbound draft: > > > > > >1) folks that want to get through NATs and Firewalls in the public=20 > > >Internet at large - they want to use TCP and TLS with=20 > double CRLF for=20 > > >keepalives. One "flow" is always one connection. The=20 > milestone for=20 > > >this would read "Make TCP and TLS work in the Internet". > > > > I agree with the intents of this community. However this is=20 > not what=20 > > the current Outbound provides. Outbound specifies two options for=20 > > keepalives for reliable connections: TCP keepalive and STUN. > > > > These options were agreed in IETF 65, a cite from the minutes: > > > > Proposal: > > Do STUN for TCP and UDP > > Do CRLF for TCP and STUN for UDP > > TCP KeepAlive if supported, 1 or 2 otherwise > > > > Resolutions: > > OS TCP KeepAlive should be used if the client supports it. > > Need something more because OS TCP KeepAlive is not supported in=20 > > every > > client OS. > > Consensus to use STUN for UDP > > Consensus to use STUN for TCP, with use of OS TCP keep=20 > alive above. > > > > In that meeting the basic assumption was that every=20 > Outbound compliant=20 > > client should implement both UDP and TCP even if that is not=20 > > explicitely mentioned in the draft. However latest -06 version now=20 > > makes that debatable by stating: > > > > Use of outbound with UDP flows typically prevents messages larger > > than 1300 bytes from being delivered using TCP as described in > > Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP > > flows in environments where requests are expected to be=20 > larger than > > this size is therefore NOT RECOMMENDED. > > > > In practice this seems to justify implementing "TCP only" UAs what=20 > > comes to the Outbound support. In that case the basic=20 > assumption with=20 > > STUN keepalive (implement it for TCP as it is anyway needed=20 > for UDP as=20 > > well) would become obsolete. For implementations which can=20 > not use TCP=20 > > keepalive, CRLF would obviously provide a great benefit without=20 > > significant increase of complexity to Outbound. > > > > > > P.S. Last week I made a proposal for "stripped Outbound"=20 > without UDP,=20 > > STUN keepalives and multiple registrations. As that=20 > proposal did not=20 > > receive any comments, I decided to propose this minimal addition to=20 > > Outbound as an alternative that might be a bit easier to accept but=20 > > still achieve some of the benefits. > > > > Regards, > > > > Erkki > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 11:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoNB-00028h-8S; Thu, 30 Nov 2006 11:02:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoNA-00028c-2t for sip@ietf.org; Thu, 30 Nov 2006 11:02:52 -0500 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoN3-0000B5-Ph for sip@ietf.org; Thu, 30 Nov 2006 11:02:52 -0500 Received: from Inbox ([89.205.156.163]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9J002QAWJVE630@jes-fe2.zx.nl> for sip@ietf.org; Thu, 30 Nov 2006 17:02:30 +0100 (CET) Date: Thu, 30 Nov 2006 17:02:27 +0100 From: Jeroen Van Bemmel Subject: RE: [Sip] Re: issue with oubound and the used transport protocol To: "Christer Holmberg (JO/LMF)" , Rohan Mahy , Erkki.Koivusalo@nokia.com Message-id: <0J9J002QBWJWE630@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Having implemented STUN over TCP/TLS I can now say that it does add signifi= cant complexity while providing little benefit over CRLF STUN allows one to detect NAT reboot, but a CRLF will also trigger a connec= tion reset in such a case. STUN breaks framing in case the other side does = not support it. It uses significantly more bandwidth than CRLF. It requires= a lot of text to describe. In summary, I support CRLF for TCP, and would suggest to do STUN only for U= DP (i.e. its original purpose). STUN for TCP is a bad idea Regards, Jeroen PS Edge proxy choosing the mechanism: not a good idea either, better to sim= ply define 1 mechanism (STUN for UDP, CRLF for TCP) -----Oorspronkelijk bericht ----- Van: "Christer Holmberg (JO/LMF)" Aan: "Rohan Mahy" ; Erkki.Koivusalo@nokia.com CC: sip@ietf.org; rohan@ekabal.com Verzonden: 30-11-06 13:56 Onderwerp: RE: [Sip] Re: issue with oubound and the used transport protocol Hi, Why don't we let the edge proxy choose which keep-alive mechanism to use? The outbound spec should now say (I haven't had time to check, but I hope me and Rohan agreed to add it :) that the edge proxy can insert the keepalive parameter in the Path header. So, we define a "CRLF" value for the parameter, and the edge proxy can then use that value for TCP flows. Of course, if the UA is not mandated to implement all kind of keep-alives, it will also have to be able to indicate to the edge proxy which keep-alive mechanisms it support. Regards, Christer =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 11:39:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpovS-0008OX-Hw; Thu, 30 Nov 2006 11:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpovQ-0008OS-P5 for sip@ietf.org; Thu, 30 Nov 2006 11:38:16 -0500 Received: from sitemail3.everyone.net ([216.200.145.37] helo=omta14.mta.everyone.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpovO-0004eX-1T for sip@ietf.org; Thu, 30 Nov 2006 11:38:16 -0500 Received: from dm21.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta14.mta.everyone.net (Postfix) with ESMTP id 5E87B40D8C; Thu, 30 Nov 2006 08:38:13 -0800 (PST) X-Eon-Dm: dm21 Received: by dm21.mta.everyone.net (EON-AUTHRELAY2[SSL] - cf31a202) id dm21.456e11f7.16aca; Thu, 30 Nov 2006 08:38:12 -0800 X-Eon-Sig: AQIH5JVFbwj0undP+wIAAAAF,1d54ce5e141b4d3bc01bc7d63b4d82f4 From: "Bala Neelakantan" To: "'Sreenath Kulkarni'" , "'Raj'" , "'SIP forum'" , , Date: Thu, 30 Nov 2006 10:38:24 -0600 Message-ID: <000201c7149d$f5c1faa0$7a02a8c0@NeelLT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: <20061129051003.75715.qmail@web7601.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Sip] RE: [Sip-implementors] Forking INVITE SIP message - regarding X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balasubramanian_neelakantan@quintum.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The 200 OK for INVITE MUST be forwarded by the SIP server. There is no priority in forwarding 200 OK. In real world scenario, once the SIP = server gets the first 200 OK for INVITE, it will send CANCEL to all the other = legs. So, the chances of getting multiple 200 OK for invite are low. Thanks, Neel -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Sreenath Kulkarni Sent: Tuesday, November 28, 2006 11:10 PM To: Raj; SIP forum; sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Forking INVITE SIP message - regarding Hi Raj, This scenario can happen only in case of parallel forking. I don't = beleive that all the 2xx responces will reach the server at the same tume. If it = so then i think the server will forward the 2xx response on some priority basis. /Sree ----- Original Message ---- From: Raj To: SIP forum ; sip@ietf.org; sip-implementors@cs.columbia.edu Sent: Tuesday, 28 November, 2006 10:47:02 PM Subject: [Sip-implementors] Forking INVITE SIP message - regarding Hello, =20 Consider the following situation. =20 Adam wants to call Bob, let?s say that Bob is registered = at three locations, that is, at home, at head office and at his branch = office. Hence, when Adam makes a call, INVITE request is forked by the proxy and = it reaches all the three destinations. Hence, three 200 OK SIP response = will be sent back to Adam.=20 =20 Consider the situation, when Bob?s friends answer the call = at all the three locations at the same time, what will happen? Either three media channel will be established between them or which two will be discarded. =20 Can anyone please clear this? =20 With regards Raj. =20 --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors =09 __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 12:39:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpprE-0005A1-Mb; Thu, 30 Nov 2006 12:38:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpprD-00058G-JE for sip@ietf.org; Thu, 30 Nov 2006 12:37:59 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpprB-0003gu-0E for sip@ietf.org; Thu, 30 Nov 2006 12:37:59 -0500 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kAUHbN229737; Thu, 30 Nov 2006 09:37:23 -0800 In-Reply-To: <7374777208BDC7449D5620EF94232567ACBA21@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF94232567ACBA21@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68a060691cfac3fc98ecd7221f098c1e@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 09:37:15 -0800 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, If we are going to revisit the keepalive decision for TCP, there is no reason to do STUN over TCP if you have CRLF. Likewise, CRLF does not work over UDP. So, the sensible decision would be to do STUN over UDP and CRLF over TCP. The alternative is to stick with STUN over TCP for "consistency" (a dubious attribute to trade off against implementation and specification complexity). thanks, -rohan On Nov 30, 2006, at 4:56, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > Why don't we let the edge proxy choose which keep-alive mechanism to > use? > > The outbound spec should now say (I haven't had time to check, but I > hope me and Rohan agreed to add it :) that the edge proxy can insert > the > keepalive parameter in the Path header. > > So, we define a "CRLF" value for the parameter, and the edge proxy can > then use that value for TCP flows. > > Of course, if the UA is not mandated to implement all kind of > keep-alives, it will also have to be able to indicate to the edge proxy > which keep-alive mechanisms it support. > > Regards, > > Christer > > > > > > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >> Sent: 29. marraskuuta 2006 20:30 >> To: Erkki.Koivusalo@nokia.com >> Cc: sip@ietf.org; rohan@ekabal.com >> Subject: Re: [Sip] Re: issue with oubound and the used >> transport protocol >> >> Hi Erkki, >> >> Clearly you are suggesting that we make CRLF mandatory to >> implement for TCP. There would be no longer any need to do >> STUN over TCP and therefore no need implement code to deal >> with stream-based demuxing. >> The text about sigcomp over TCP and STUN over TLS over TCP >> could also go away. >> >> To clarify are you suggesting that an edge proxy can >> implement outbound without support for UDP flow tokens, >> without support for STUN keepalives over UDP, both, or neither? >> >> thanks, >> -rohan >> >> On 11/29/06, Erkki.Koivusalo@nokia.com >> wrote: >>> >>> Hi, >>> >>>> about STUN keepalive usage and discovery, since double >> CRLF is fully >>>> backwards compatible with even RFC 2543 implementations. I am >>>> bringing this up on the list because I hope the WG can >> look back on >>>> this and not make the mistake of snowballing complexity to >> preserve >>>> UDP parity again in the future. >>> >>> Rohan is making a valid point here and I believe in >> Outbound there is >>> still room for change to cater for CRLF keepalives as an option to >>> STUN keepalives over TCP. >>> >>> I am calling the WG to look back on the keepalive decision made >>> earlier for TCP and proposing that Outbound should also cover CRLF >>> keepalive option. >>> >>> Reasons for this proposal: >>> >>>> The problem I see is that we have two separate communities >> using the >>>> outbound draft: >>>> >>>> 1) folks that want to get through NATs and Firewalls in the public >>>> Internet at large - they want to use TCP and TLS with >> double CRLF for >>>> keepalives. One "flow" is always one connection. The >> milestone for >>>> this would read "Make TCP and TLS work in the Internet". >>> >>> I agree with the intents of this community. However this is >> not what >>> the current Outbound provides. Outbound specifies two options for >>> keepalives for reliable connections: TCP keepalive and STUN. >>> >>> These options were agreed in IETF 65, a cite from the minutes: >>> >>> Proposal: >>> Do STUN for TCP and UDP >>> Do CRLF for TCP and STUN for UDP >>> TCP KeepAlive if supported, 1 or 2 otherwise >>> >>> Resolutions: >>> OS TCP KeepAlive should be used if the client supports it. >>> Need something more because OS TCP KeepAlive is not supported in >>> every >>> client OS. >>> Consensus to use STUN for UDP >>> Consensus to use STUN for TCP, with use of OS TCP keep >> alive above. >>> >>> In that meeting the basic assumption was that every >> Outbound compliant >>> client should implement both UDP and TCP even if that is not >>> explicitely mentioned in the draft. However latest -06 version now >>> makes that debatable by stating: >>> >>> Use of outbound with UDP flows typically prevents messages larger >>> than 1300 bytes from being delivered using TCP as described in >>> Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP >>> flows in environments where requests are expected to be >> larger than >>> this size is therefore NOT RECOMMENDED. >>> >>> In practice this seems to justify implementing "TCP only" UAs what >>> comes to the Outbound support. In that case the basic >> assumption with >>> STUN keepalive (implement it for TCP as it is anyway needed >> for UDP as >>> well) would become obsolete. For implementations which can >> not use TCP >>> keepalive, CRLF would obviously provide a great benefit without >>> significant increase of complexity to Outbound. >>> >>> >>> P.S. Last week I made a proposal for "stripped Outbound" >> without UDP, >>> STUN keepalives and multiple registrations. As that >> proposal did not >>> receive any comments, I decided to propose this minimal addition to >>> Outbound as an alternative that might be a bit easier to accept but >>> still achieve some of the benefits. >>> >>> Regards, >>> >>> Erkki >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 12:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppyN-0004U0-EJ; Thu, 30 Nov 2006 12:45:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppyL-0004Tv-Nw for sip@ietf.org; Thu, 30 Nov 2006 12:45:21 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppyI-0004uD-BA for sip@ietf.org; Thu, 30 Nov 2006 12:45:21 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUHjBR25512; Thu, 30 Nov 2006 12:45:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 11:45:02 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E379B63@zrc2hxm0.corp.nortel.com> In-Reply-To: <0J9J002QBWJWE630@jes-fe2.zx.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccUmZHhE1qIgh9rQ86y3AHXyVT30wADVBkw From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN instead? Why is this debate being re-opened? Remember: I favored the non-STUN TCP approach. However, if we can't stick to a decision, we'll debate this forever. It already feels like it. > -----Original Message----- > From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Thursday, November 30, 2006 08:02 > To: Christer Holmberg (JO/LMF); Rohan Mahy; Erkki.Koivusalo@nokia.com > Cc: sip@ietf.org; rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Having implemented STUN over TCP/TLS I can now say that it=20 > does add significant complexity while providing little=20 > benefit over CRLF >=20 > STUN allows one to detect NAT reboot, but a CRLF will also=20 > trigger a connection reset in such a case. STUN breaks=20 > framing in case the other side does not support it. It uses=20 > significantly more bandwidth than CRLF. It requires a lot of=20 > text to describe. >=20 > In summary, I support CRLF for TCP, and would suggest to do=20 > STUN only for UDP (i.e. its original purpose). STUN for TCP=20 > is a bad idea >=20 > Regards, > Jeroen >=20 > PS Edge proxy choosing the mechanism: not a good idea either,=20 > better to simply define 1 mechanism (STUN for UDP, CRLF for TCP) >=20 > -----Oorspronkelijk bericht ----- > Van: "Christer Holmberg (JO/LMF)" > Aan: "Rohan Mahy" ; Erkki.Koivusalo@nokia.com > CC: sip@ietf.org; rohan@ekabal.com > Verzonden: 30-11-06 13:56 > Onderwerp: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > Hi, >=20 > Why don't we let the edge proxy choose which keep-alive=20 > mechanism to use? >=20 > The outbound spec should now say (I haven't had time to=20 > check, but I hope me and Rohan agreed to add it :) that the=20 > edge proxy can insert the keepalive parameter in the Path header. >=20 > So, we define a "CRLF" value for the parameter, and the edge=20 > proxy can then use that value for TCP flows. >=20 > Of course, if the UA is not mandated to implement all kind of=20 > keep-alives, it will also have to be able to indicate to the=20 > edge proxy which keep-alive mechanisms it support. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 13:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqTH-0005cp-BT; Thu, 30 Nov 2006 13:17:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqTG-0005a4-FU for sip@ietf.org; Thu, 30 Nov 2006 13:17:18 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqTF-0000l2-2o for sip@ietf.org; Thu, 30 Nov 2006 13:17:18 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id kAUIH4GA020981; Thu, 30 Nov 2006 11:17:04 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 30 Nov 2006 11:17:03 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Date: Thu, 30 Nov 2006 11:17:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] strawman text for FASTEST proposal in outbound Thread-Index: AccN0/DhaVfBQAGgTxakDnaeYahaJgAer/UgAV09JCAAOeCu8A== From: "Kevin Johns" To: "Christer Holmberg (JO/LMF)" , "Rohan Mahy" , "Francois Audet" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: SIP WG , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, The issue is not so much whether the devices can determine if a NAT is present or not, but rather whether outbound does prohibit changing from UDP to TCP. I was indicating that I did not see that restriction in outbound. I went back and took another look and see that a flow is defined in include the protocol and a flow toke is suppose to be unique to a flow. These two imply a one to one relationship between a flow and a flow token. Given this, I can now see a restriction as a flow token can only identify a single flow, which would be UDP and thus prohibit a connection reuse scenario for a UA initiated TCP connection or a Edge Proxy TCP initiated connection. This relationship may need to be revisited based on some of the mid-dialog solutions being proposed. Kevin -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Thursday, November 30, 2006 1:28 AM To: Kevin Johns; Rohan Mahy; Francois Audet Cc: SIP WG; Cullen Jennings; Rohan Mahy Subject: RE: [Sip] strawman text for FASTEST proposal in outbound Hi,=20 >I am in favor of FASTEST, however I am not sure the text being proposed >is necessary. How does outbound prohibit the change to TCP? >=20 >This seems to be an issue of how the algorithm for generating the flow=20 >token is implemented and those in outbound are informational from my=20 >reading. Thus, as long as the edge proxy utilizes an algorithm which=20 >generates a flow token which resolves to a source IP and Port and=20 >Destination IP and Port the edge proxy would be free to determine which >transport protocol to use. >=20 >If a NAT is present, the UA will need to establish both a UDP and TCP=20 >flow to the edge proxy to allow inbound requests on either. If a NAT is >not present, then the UA need only establish one flow as the edge proxy >can initial the other flow if needed. How does the UA knows whether there is a NAT or not? How does the edge proxy knows whether there is a NAT or not? Regards, Christer > =20 >=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Tuesday, November 21, 2006 6:15 PM > To: Francois Audet > Cc: SIP WG; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] strawman text for FASTEST proposal in outbound >=20 > Hi Francois, >=20 > On 11/21/06, Francois Audet wrote: > > > > > To make the discussion about the outbound transport issues more=20 > > > concrete, here is some strawman text for the "FASTEST" direction. > > > > > > thanks, > > > -rohan > > > > > > PROPOSED TEXT: > > > Use of outbound with UDP flows prevents messages larger than 1300=20 > > > bytes from being delivered using TCP as described in > > ^^^ > > Shouldn't this say "UDP"? >=20 > No. Outbound using UDP flows prevents the switchover to a=20 > congestion-controlled transport, such as TCP as described in this=20 > quote from RFC 3261: >=20 > If a request is within 200 bytes of the path MTU, or if it is=20 > larger than 1300 bytes and the path MTU is unknown, the request MUST=20 > be sent using an RFC 2914 [36] congestion controlled transport=20 > protocol, such as TCP. If this causes a change in the transport=20 > protocol from the one indicated in the top Via, the value in the top=20 > Via MUST be changed. This prevents fragmentation of messages over UDP=20 > and provides congestion control for larger messages. >=20 > thanks, > -rohan >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 13:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqXz-0000UE-6p; Thu, 30 Nov 2006 13:22:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqXx-0000Qt-AL for sip@ietf.org; Thu, 30 Nov 2006 13:22:09 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqXv-0001C4-17 for sip@ietf.org; Thu, 30 Nov 2006 13:22:09 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 63EDC3BEB0; Thu, 30 Nov 2006 19:21:53 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23856-02-24; Thu, 30 Nov 2006 19:21:53 +0100 (CET) Received: from [192.168.123.17] (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id DB3133BE68; Thu, 30 Nov 2006 19:21:52 +0100 (CET) Message-ID: <456F2127.4030007@it.su.se> Date: Thu, 30 Nov 2006 19:21:27 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <1ECE0EB50388174790F9694F77522CCF0E379B63@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E379B63@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.567 tagged_above=-99 required=7 tests=[AWL=0.098, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN > instead? > > Why is this debate being re-opened? Because it seems more and more (to me at least) that Outbound with UDP will just suck. If Outbound UA's have to get their act together and implement TLS/TCP, then we can simplify Outbound even further by skipping the whole STUN keepalive thing, and go with CRLF over TLS/TCP. I am very much in favor of cutting both UDP and STUN keepalives out of Outbound. I think that would lead to faster deployment, and also make the world a better place by eliminating some SIP over UDP. /Fredrik PS. By the way, when people say CRLF keepalives, do you mean CRLF sent only from the UA, or CRLF from UA to edge proxy followed by CRLF in the reverse direction too? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 14:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprJm-0005FU-DC; Thu, 30 Nov 2006 14:11:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprJl-0005FL-4c for sip@ietf.org; Thu, 30 Nov 2006 14:11:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprJj-000753-Rh for sip@ietf.org; Thu, 30 Nov 2006 14:11:33 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 11:11:30 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAUJBTZQ005067; Thu, 30 Nov 2006 11:11:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAUJBSj2025434; Thu, 30 Nov 2006 11:11:29 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:11:27 -0800 Received: from [70.96.146.253] ([10.21.123.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:11:27 -0800 In-Reply-To: <456EA08B.6070102@it.su.se> References: <7374777208BDC7449D5620EF94232567A940F4@esealmw113.eemea.ericsson.se> <456EA08B.6070102@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Date: Thu, 30 Nov 2006 11:11:37 -0800 To: Fredrik Thulin , SIP , Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Nov 2006 19:11:27.0462 (UTC) FILETIME=[55CE1860:01C714B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=462; t=1164913889; x=1165777889; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20strawman=20text=20for=20FASTEST=20proposal=20 in=20outbound |Sender:=20; bh=iBJn4VNQVw6ALgf8KSdL4ur5DCXYCBCC+ZX1Gx5S5jQ=; b=Qk/m1ad+0bQ4tE/wuUY4alKv179wplugxNuNNy/WG6Sg70KJWmxRC50SZD3PzJEUuL5FGvYC vDeP3AyenWLJgx9Z6CvfxBeek8SO3LWPkU8rO87mC18fkEZrypzsdBKc; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Francois Audet , Kevin Johns , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 30, 2006, at 1:12 AM, Fredrik Thulin wrote: > Christer Holmberg (JO/LMF) wrote: > ... >> How does the UA knows whether there is a NAT or not? How does the >> edge >> proxy knows whether there is a NAT or not? > > Also remember that it doesn't have to be a NAT that we have to use > Outbound to work around either - it can be a statefull firewall as > well. > > /Fredrik I was just about to say this but Fredrik beat me too 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 From sip-bounces@ietf.org Thu Nov 30 14:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprYw-00042f-N8; Thu, 30 Nov 2006 14:27:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprYv-0003yx-IW for sip@ietf.org; Thu, 30 Nov 2006 14:27:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprYt-0000rC-8J for sip@ietf.org; Thu, 30 Nov 2006 14:27:13 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 11:27:11 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kAUJRAR7020840; Thu, 30 Nov 2006 11:27:10 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAUJR7OZ017158; Thu, 30 Nov 2006 11:27:08 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:27:08 -0500 Received: from [10.86.240.35] ([10.86.240.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:27:07 -0500 Message-ID: <456F308A.8000004@cisco.com> Date: Thu, 30 Nov 2006 14:27:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <50B1CBA96870A34799A506B2313F26670A76AB7A@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A76AB7A@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2006 19:27:07.0810 (UTC) FILETIME=[864BD020:01C714B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9849; t=1164914830; x=1165778830; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20; bh=QFV2eOqSoWZis8RDQns4hEa+cjTWoJYGfob7H+JiE9w=; b=L2EZDflqXfbgxo2bJZ6ciZ0JkPggNkyPRFxZ6BsdkUgzjjHaBvZQEcazM85G4l6lSrAMpAr9 S42PZG+C2Ufl5rjGEcSW2oUdAd2ORn9xjSpZDpO0//RcM5vtTPJjTLE3; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > I guess some of my concerns about temporary GRUUs are starting to creep back > again. Is your renewed concern related to this particular issue I posted? It doesn't seem to be. Your concern seems to be that temporary gruus are, well, *temporary*. > It is a question of how they are used. If a UA gives a temporary GRUU > out as a contact on a dialog and expects it to be used only during the > lifetime of that dialog, then refreshing the target if the temporary GRUU is > lost would get around the problem in most cases. There will of course be > race conditions, e.g., the UA sends out a target refresh but the remote UA > has already sent a REFER request to the old target. Yes. In most cases this won't be an issue. And I expect that many implementations will simply assume that they stay registered and don't need to deal with the doing a target refresh because the gruu has been lost. > What concerns me more is if there are use cases where a remote UA might want > to use a received temporary GRUU long after the dialog has terminated. If > the local UA keeps refreshing its subscription correctly and successfully, > then the temporary GRUU will remain valid. But if it is lost through > circumstances beyond the control of the local UA, then it has no means to > inform the remote UA that it is no longer valid and that a different > temporary GRUU must be used. Yes, this is the case. Frankly I find it hard to imagine a case where a temp-gruu, used for anonymity, is to be used for something long after the dialog has terminated. I guess there could be cases, but perhaps they aren't so interesting. Any kind of scheme that allowed temp gruus to live arbitrarily beyond the life of a registration would need some other mechanism to support their longevity, and also would presumably need some kind of revocation mechanism. It would I think need state to be kept in the network. There may be some use for such a thing. But I think it probably calls for a different mechanism. One that probably isn't suitable for everyday anonymous calls. So I think supporting that mechanism can be viewed as an independent problem. > One example given in gruu-11 is the use of a GRUU on a web page. If a > temporary GRUU were to be used (presumably on a temporary web page), similar > considerations would apply. I guess it depends on how temporary the web page is. > Another concern is if I want to give out a different temporary GRUU to > different remote UAs, so that I can easily turn off individual temporary > GRUUs if I no longer wish to receive requests from the parties concerned. > When I first register I have only one temporary GRUU, so if I want to give > out several temporary GRUUs I would need to refresh my subscription several > times to obtain these GRUUs. > > I just have an uneasy feeling that the temporary GRUU mechanism might be > somewhat orthogonal to possible use cases, although I am having difficulty > articulating particular real life use cases. I think we already hashed these particular issues. There are some unavoidable tradeoffs here. Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 29 November 2006 23:21 >> To: SIP IETF >> Subject: [Sip] Issue: Expiration of temp-gruu >> >> After some study, I have encountered a potential difficulty in >> determining when temp-gruus expire. After discussing this >> with Jonathan >> we decided to bring it to the list for discussion. >> >> As now defined, when you first register you may get a >> temp-gruu, which >> will remain valid as long as the registration does not expire or be >> removed. (Removal is a special case of expiration.) Each time the UA >> refreshes the registration it may get a new temp-gruu which >> also remains >> valid for the life of the registration. The UA can accumulate >> all these >> temp-gruus and use them as it sees fit until they expire. >> >> The problem is: how does the UA know when the registration >> has ended and >> the temp-gruus associated with it rendered invalid? >> >> This seems like a simple question, and in some cases it is >> simple, but >> not in all cases. The following are at least some of the ways >> that the >> registration can be ended, causing the invalidation of temp-gruus: >> 1) the UA that originally registered may explicitly deregister >> 2) the UA the originally registered may simply permit the >> registration to expire without attempting to refresh it >> 3) the UA may attempt to refresh the registration, but be too slow, >> so that the reregistration arrives after the prior one expires >> 4) some other UA may deregister all the registrations, including >> the one by this UA. (When the UA decides it should refresh the >> registration it will actually create a new one.) >> 5) the registrar may remove the registration administratively >> 6) the registrar may crash and restart, losing all its registrations >> >> In each of these cases the previously assigned temp-gruus become >> invalid. If the UA continues to use them, bad things will >> happen. This >> is true both for calls that are active when the >> deregistration occurs, >> and calls that are established later. What kinds of bad things happen? >> - requests addressed to the gruu, both in-dialog and out-of-dialog >> will be undeliverable. (For instance a reINVITE or BYE in an >> existing call, or an out-of-dialog INVITE/Replaces for a transfer.) >> >> - request originated by the UA using the invalid gruu will fail >> immediately because the gruu is invalid. >> >> - if the UA subsequently reregisters, receives an incoming call, and >> uses one of the old temp-gruus as its contact, then the call will >> be established, but subsequent in- and out-of-dialog requests to >> the contact will fail. >> >> So clearly it is important for the UA to stop using >> temp-gruus that have >> become invalid. How can it know to do that in all of the above cases? >> >> 1) is straightforward. The UA knows it is deregistering, and should >> discard any cached temp-gruus. If it has a dialog with one of the >> temp-gruus as a contact, then it should do a target refresh and >> supply some working contact. (It really should do this *before* >> deregistering, and for a pub-gruu as well.) >> >> 2) the UA should take all the actions mentioned for (1) at or before >> the expiration time. This should be done a bit early to guard >> against clock skew problems. >> >> 3) in this case, it may be impossible for the UA to know whether >> the REGISTER arrived in time to be a reREGISTER or if it arrived >> late and was treated as a new REGISTER after the expiration of >> the old one. (The response to the REGISTER includes nothing that >> distinguishes the two cases.) About the best that can be done in >> this case is to check the time at which the response to the >> REGISTER is received. If it falls after the expected expiration >> time for the registration, act as if the old registration had >> expired. >> >> 4) This is a major problem. Of course, regardless of GRUU, the UA >> won't be able to receive incoming calls until it decides it is >> time to refresh the registration. In addition, until the >> registration reestablished, calls originated with one of its >> existing gruus will fail. Once the registration is reestablished, >> it still won't know its old temp-gruus are invalid. The only >> remedy for this is to subscribe to the "reg" event package, >> and use the resulting notifications to identify when it has >> been unregistered. If it does that, it can invalidate all its >> old temp-gruus, and then presumably reregister. >> >> 5) this is functionally equivalent to (4), except that perhaps >> attempts to reregister may fail. >> >> 6) this is also functionally equivalent to (4). >> >> The "reg" event does provide a fairly complete solution to >> this problem, >> for those that are willing and able to use it. It is not >> however a 100% >> reliable solution. Consider case (3), where the UA has a reg event >> subscription. All is well if the registration expires and a >> notification >> is sent indicating that, and then the reregistration occurs and a >> notification is sent about that. But if they happen very closely in >> time, it may be that only one notification is sent, reflecting the >> result of the reregistration. In that case the UA will not be >> aware that >> it had been unregistered for a period of time. >> >> A *complete* solution would, IMO, involve changing REGISTER >> so that it >> returns an indication of whether this was a new registration, or a >> refresh. This could take many forms. For instance the >> timestamp of the >> initial registration could always be returned with each >> contact, as well >> as the expiration time. >> >> The big question is whether this is a big enough issue to require a >> solution now, as part of GRUU, or if it can be ignored as >> insignificant >> or postponed to future work. >> >> I'd appreciate hearing what others think about this. At the >> moment I am >> leaning toward doing nothing, at least for now. >> >> Thanks, >> 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 >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 14:38:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprjF-00022C-9T; Thu, 30 Nov 2006 14:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprjD-0001zU-KN for sip@ietf.org; Thu, 30 Nov 2006 14:37:51 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprjB-0002IN-BA for sip@ietf.org; Thu, 30 Nov 2006 14:37:51 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUJbkT04617; Thu, 30 Nov 2006 14:37:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 13:37:40 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E379DE1@zrc2hxm0.corp.nortel.com> In-Reply-To: <456F2127.4030007@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccUrG6zKoIal/J8TPaXiSc5msUvCQACW5GA From: "Francois Audet" To: "Fredrik Thulin" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to be clear what my opinion is... I agree with you that using CRLF with TCP would be a lot cleaner and easier to implement. It would really make the UDP-with-STUN alternative a moot point. That combined with people moving to TLS/TCP for security=20 reasons in my opinion means that having focused our energies on a solution optimized for UDP was a big mistake. The consequence is the plethora of mechanisms that people are using today: PING, OPTIONS, CRLF, REGISTER, etc. But in my opinion, getting the document finalized should be the ultimate priority. > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se]=20 > Sent: Thursday, November 30, 2006 10:21 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Francois Audet wrote: > > Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN=20 > > instead? > >=20 > > Why is this debate being re-opened? >=20 > Because it seems more and more (to me at least) that Outbound=20 > with UDP will just suck. >=20 > If Outbound UA's have to get their act together and implement=20 > TLS/TCP, then we can simplify Outbound even further by=20 > skipping the whole STUN keepalive thing, and go with CRLF=20 > over TLS/TCP. >=20 > I am very much in favor of cutting both UDP and STUN=20 > keepalives out of Outbound. I think that would lead to faster=20 > deployment, and also make the world a better place by=20 > eliminating some SIP over UDP. >=20 > /Fredrik >=20 > PS. By the way, when people say CRLF keepalives, do you mean=20 > CRLF sent only from the UA, or CRLF from UA to edge proxy=20 > followed by CRLF in the reverse direction too? >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 15:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpsl9-0005Qz-4b; Thu, 30 Nov 2006 15:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpsl7-0005Qt-To for sip@ietf.org; Thu, 30 Nov 2006 15:43:53 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpsl3-0001gl-By for sip@ietf.org; Thu, 30 Nov 2006 15:43:53 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id kAUKfQL22683; Thu, 30 Nov 2006 14:41:26 -0600 Message-Id: <200611302041.kAUKfQL22683@celine.siteprotect.com> From: "Frank W. Miller" To: "'Francois Audet'" , "'Fredrik Thulin'" , , Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 13:41:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccUrG6zKoIal/J8TPaXiSc5msUvCQACW5GAAAJw6gA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E379DE1@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As an aside, the draft draft-fwmiller-ping-03 has expired. While the draft is still available at http://www.cornfed.com/ping.html and http://www.cornfed.com/ping.txt, the question is whether it should be resubmitted? If there is no interest in it, I'll let it die on the IETF site. Thanks, FM -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Thursday, November 30, 2006 12:38 PM To: Fredrik Thulin; sip@ietf.org; rohan@ekabal.com Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Just to be clear what my opinion is... I agree with you that using CRLF with TCP would be a lot cleaner and easier to implement. It would really make the UDP-with-STUN alternative a moot point. That combined with people moving to TLS/TCP for security reasons in my opinion means that having focused our energies on a solution optimized for UDP was a big mistake. The consequence is the plethora of mechanisms that people are using today: PING, OPTIONS, CRLF, REGISTER, etc. But in my opinion, getting the document finalized should be the ultimate priority. > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: Thursday, November 30, 2006 10:21 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Re: issue with oubound and the used > transport protocol > > Francois Audet wrote: > > Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN > > instead? > > > > Why is this debate being re-opened? > > Because it seems more and more (to me at least) that Outbound > with UDP will just suck. > > If Outbound UA's have to get their act together and implement > TLS/TCP, then we can simplify Outbound even further by > skipping the whole STUN keepalive thing, and go with CRLF > over TLS/TCP. > > I am very much in favor of cutting both UDP and STUN > keepalives out of Outbound. I think that would lead to faster > deployment, and also make the world a better place by > eliminating some SIP over UDP. > > /Fredrik > > PS. By the way, when people say CRLF keepalives, do you mean > CRLF sent only from the UA, or CRLF from UA to edge proxy > followed by CRLF in the reverse direction too? > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 15:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpso7-0001Nm-HT; Thu, 30 Nov 2006 15:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpso6-0001Nh-Li for sip@ietf.org; Thu, 30 Nov 2006 15:46:58 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpso4-0001yy-7h for sip@ietf.org; Thu, 30 Nov 2006 15:46:58 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id kAUKklxg006714; Thu, 30 Nov 2006 13:46:47 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 30 Nov 2006 13:46:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 13:46:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQ From: "Kevin Johns" To: "Fredrik Thulin" , "Francois Audet" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Not all architectures use TLS/TCP, some use UDP encapsulated IPsec. Would a TCP session via UDP encapsulated IPsec be impacted by this? I do not think it would, but just wanted to double check... Kevin -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se]=20 Sent: Thursday, November 30, 2006 11:21 AM To: Francois Audet Cc: sip@ietf.org; rohan@ekabal.com Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Francois Audet wrote: > Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN=20 > instead? >=20 > Why is this debate being re-opened? Because it seems more and more (to me at least) that Outbound with UDP will just suck. If Outbound UA's have to get their act together and implement TLS/TCP, then we can simplify Outbound even further by skipping the whole STUN keepalive thing, and go with CRLF over TLS/TCP. I am very much in favor of cutting both UDP and STUN keepalives out of Outbound. I think that would lead to faster deployment, and also make the world a better place by eliminating some SIP over UDP. /Fredrik PS. By the way, when people say CRLF keepalives, do you mean CRLF sent only from the UA, or CRLF from UA to edge proxy followed by CRLF in the reverse direction too? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDa-00045y-KP; Thu, 30 Nov 2006 16:13:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptD3-0003It-Hy for sip@ietf.org; Thu, 30 Nov 2006 16:12:45 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpt6k-0005F5-Qn for sip@ietf.org; Thu, 30 Nov 2006 16:06:20 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1975A798; Thu, 30 Nov 2006 22:06:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:06:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:06:04 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF83DF@esealmw113.eemea.ericsson.se> In-Reply-To: <456F2127.4030007@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUrIiMZBlDSOnAQS2wG2vJO7jRgQAFoleg From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , "Francois Audet" X-OriginalArrivalTime: 30 Nov 2006 21:06:05.0871 (UTC) FILETIME=[59A803F0:01C714C3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN=20 >>instead? >>=20 >>Why is this debate being re-opened? >=20 >Because it seems more and more (to me at least) that Outbound=20 >with UDP will just suck. >=20 >If Outbound UA's have to get their act together and implement=20 >TLS/TCP, then we can simplify Outbound even further by=20 >skipping the whole STUN keepalive thing, and go with CRLF=20 >over TLS/TCP. >=20 >I am very much in favor of cutting both UDP and STUN=20 >keepalives out of Outbound. I think that would lead to faster=20 >deployment, and also make the world a better place by=20 >eliminating some SIP over UDP. We have to remember that outbound can now also be used in no-NAT scenarios, in order to support multiple simultanous registrations, in which case keep-alives aren't needed in the first place. Just to keep in mind. Regards, Christer >=20 > /Fredrik >=20 > PS. By the way, when people say CRLF keepalives, do you mean=20 > CRLF sent only from the UA, or CRLF from UA to edge proxy=20 > followed by CRLF in the reverse direction too? >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:18:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptIK-0007di-K5; Thu, 30 Nov 2006 16:18:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptIJ-0007ce-AR for sip@ietf.org; Thu, 30 Nov 2006 16:18:11 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GptIG-0000iY-4r for sip@ietf.org; Thu, 30 Nov 2006 16:18:11 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7410E4A7; Thu, 30 Nov 2006 22:18:05 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:18:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:18:04 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF83F2@esealmw113.eemea.ericsson.se> In-Reply-To: <68a060691cfac3fc98ecd7221f098c1e@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUplQ3l66vxYMjRfS/slVROWR6jAAHi2qg From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 30 Nov 2006 21:18:05.0237 (UTC) FILETIME=[066E8E50:01C714C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >If we are going to revisit the keepalive decision for TCP,=20 >there is no reason to do STUN over TCP if you have CRLF. =20 >Likewise, CRLF does not work over UDP. So, the sensible=20 >decision would be to do STUN over UDP and CRLF over TCP. The=20 >alternative is to stick with STUN over TCP for "consistency"=20 >(a dubious attribute to trade off against implementation and=20 >specification complexity). We may still need a new value for the keepalive parameter, eventhough specific support is probably not required in order to receive CRLFs. ...OR, we simply use the parameter without a value, to indicate that keep-alive is supported, but the actual mechanism is then based on the transport protocol. I don't think "keepalive=3Dstun" would be very good in the outbound = proxy set either, in case the DNS lookup would result in using TCP. Regards, Christer > On Nov 30, 2006, at 4:56, Christer Holmberg ((JO/LMF)) wrote: > > > > Hi, > > > > Why don't we let the edge proxy choose which keep-alive=20 > mechanism to=20 > > use? > > > > The outbound spec should now say (I haven't had time to=20 > check, but I=20 > > hope me and Rohan agreed to add it :) that the edge proxy=20 > can insert=20 > > the keepalive parameter in the Path header. > > > > So, we define a "CRLF" value for the parameter, and the=20 > edge proxy can=20 > > then use that value for TCP flows. > > > > Of course, if the UA is not mandated to implement all kind of=20 > > keep-alives, it will also have to be able to indicate to the edge=20 > > proxy which keep-alive mechanisms it support. > > > > Regards, > > > > Christer > > > > > > > > > > > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > >> Sent: 29. marraskuuta 2006 20:30 > >> To: Erkki.Koivusalo@nokia.com > >> Cc: sip@ietf.org; rohan@ekabal.com > >> Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > >> protocol > >> > >> Hi Erkki, > >> > >> Clearly you are suggesting that we make CRLF mandatory to=20 > implement=20 > >> for TCP. There would be no longer any need to do STUN=20 > over TCP and=20 > >> therefore no need implement code to deal with stream-based=20 > demuxing. > >> The text about sigcomp over TCP and STUN over TLS over TCP could=20 > >> also go away. > >> > >> To clarify are you suggesting that an edge proxy can implement=20 > >> outbound without support for UDP flow tokens, without support for=20 > >> STUN keepalives over UDP, both, or neither? > >> > >> thanks, > >> -rohan > >> > >> On 11/29/06, Erkki.Koivusalo@nokia.com =20 > >> wrote: > >>> > >>> Hi, > >>> > >>>> about STUN keepalive usage and discovery, since double > >> CRLF is fully > >>>> backwards compatible with even RFC 2543 implementations. I am=20 > >>>> bringing this up on the list because I hope the WG can > >> look back on > >>>> this and not make the mistake of snowballing complexity to > >> preserve > >>>> UDP parity again in the future. > >>> > >>> Rohan is making a valid point here and I believe in > >> Outbound there is > >>> still room for change to cater for CRLF keepalives as an=20 > option to=20 > >>> STUN keepalives over TCP. > >>> > >>> I am calling the WG to look back on the keepalive decision made=20 > >>> earlier for TCP and proposing that Outbound should also=20 > cover CRLF=20 > >>> keepalive option. > >>> > >>> Reasons for this proposal: > >>> > >>>> The problem I see is that we have two separate communities > >> using the > >>>> outbound draft: > >>>> > >>>> 1) folks that want to get through NATs and Firewalls in=20 > the public=20 > >>>> Internet at large - they want to use TCP and TLS with > >> double CRLF for > >>>> keepalives. One "flow" is always one connection. The > >> milestone for > >>>> this would read "Make TCP and TLS work in the Internet". > >>> > >>> I agree with the intents of this community. However this is > >> not what > >>> the current Outbound provides. Outbound specifies two options for=20 > >>> keepalives for reliable connections: TCP keepalive and STUN. > >>> > >>> These options were agreed in IETF 65, a cite from the minutes: > >>> > >>> Proposal: > >>> Do STUN for TCP and UDP > >>> Do CRLF for TCP and STUN for UDP > >>> TCP KeepAlive if supported, 1 or 2 otherwise > >>> > >>> Resolutions: > >>> OS TCP KeepAlive should be used if the client supports it. > >>> Need something more because OS TCP KeepAlive is not=20 > supported in=20 > >>> every > >>> client OS. > >>> Consensus to use STUN for UDP > >>> Consensus to use STUN for TCP, with use of OS TCP keep > >> alive above. > >>> > >>> In that meeting the basic assumption was that every > >> Outbound compliant > >>> client should implement both UDP and TCP even if that is not=20 > >>> explicitely mentioned in the draft. However latest -06=20 > version now=20 > >>> makes that debatable by stating: > >>> > >>> Use of outbound with UDP flows typically prevents=20 > messages larger > >>> than 1300 bytes from being delivered using TCP as described in > >>> Section 18.1.1 RFC 3261. Use of outbound in=20 > conjunction with UDP > >>> flows in environments where requests are expected to be > >> larger than > >>> this size is therefore NOT RECOMMENDED. > >>> > >>> In practice this seems to justify implementing "TCP only"=20 > UAs what=20 > >>> comes to the Outbound support. In that case the basic > >> assumption with > >>> STUN keepalive (implement it for TCP as it is anyway needed > >> for UDP as > >>> well) would become obsolete. For implementations which can > >> not use TCP > >>> keepalive, CRLF would obviously provide a great benefit without=20 > >>> significant increase of complexity to Outbound. > >>> > >>> > >>> P.S. Last week I made a proposal for "stripped Outbound" > >> without UDP, > >>> STUN keepalives and multiple registrations. As that > >> proposal did not > >>> receive any comments, I decided to propose this minimal=20 > addition to=20 > >>> Outbound as an alternative that might be a bit easier to=20 > accept but=20 > >>> still achieve some of the benefits. > >>> > >>> Regards, > >>> > >>> Erkki > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptMI-0003Z2-50; Thu, 30 Nov 2006 16:22:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptMH-0003Yb-JP for sip@ietf.org; Thu, 30 Nov 2006 16:22:17 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GptMD-00010r-RZ for sip@ietf.org; Thu, 30 Nov 2006 16:22:17 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A85A24F0002; Thu, 30 Nov 2006 22:22:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:22:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:22:05 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF83F6@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E379B63@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUmZHhE1qIgh9rQ86y3AHXyVT30wADVBkwAAeQTzA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , X-OriginalArrivalTime: 30 Nov 2006 21:22:06.0421 (UTC) FILETIME=[96305050:01C714C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, A question for clarification: The STUN response provides the UA with certain useful information (XOR-ADDRESS etc), which the UA can use to see whether a NAT has rebooted etc. I assume that information is not needed when using TCP? Regards, Christer =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 30. marraskuuta 2006 19:45 > To: sip@ietf.org > Cc: rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Didn't we agree way back NOT to use PING, CRLF, etc., and use=20 > STUN instead? >=20 > Why is this debate being re-opened? >=20 > Remember: I favored the non-STUN TCP approach. However, if we=20 > can't stick to a decision, we'll debate this forever. It=20 > already feels like it. >=20 > > -----Original Message----- > > From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: Thursday, November 30, 2006 08:02 > > To: Christer Holmberg (JO/LMF); Rohan Mahy;=20 > Erkki.Koivusalo@nokia.com > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > > Having implemented STUN over TCP/TLS I can now say that it does add=20 > > significant complexity while providing little benefit over CRLF > >=20 > > STUN allows one to detect NAT reboot, but a CRLF will also=20 > trigger a=20 > > connection reset in such a case. STUN breaks framing in=20 > case the other=20 > > side does not support it. It uses significantly more bandwidth than=20 > > CRLF. It requires a lot of text to describe. > >=20 > > In summary, I support CRLF for TCP, and would suggest to do=20 > STUN only=20 > > for UDP (i.e. its original purpose). STUN for TCP is a bad idea > >=20 > > Regards, > > Jeroen > >=20 > > PS Edge proxy choosing the mechanism: not a good idea=20 > either, better=20 > > to simply define 1 mechanism (STUN for UDP, CRLF for TCP) > >=20 > > -----Oorspronkelijk bericht ----- > > Van: "Christer Holmberg (JO/LMF)" > > Aan: "Rohan Mahy" ; Erkki.Koivusalo@nokia.com > > CC: sip@ietf.org; rohan@ekabal.com > > Verzonden: 30-11-06 13:56 > > Onderwerp: RE: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > >=20 > > Hi, > >=20 > > Why don't we let the edge proxy choose which keep-alive=20 > mechanism to=20 > > use? > >=20 > > The outbound spec should now say (I haven't had time to=20 > check, but I=20 > > hope me and Rohan agreed to add it :) that the edge proxy=20 > can insert=20 > > the keepalive parameter in the Path header. > >=20 > > So, we define a "CRLF" value for the parameter, and the=20 > edge proxy can=20 > > then use that value for TCP flows. > >=20 > > Of course, if the UA is not mandated to implement all kind of=20 > > keep-alives, it will also have to be able to indicate to the edge=20 > > proxy which keep-alive mechanisms it support. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptYH-0002iq-AC; Thu, 30 Nov 2006 16:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptYF-0002hB-9O for sip@ietf.org; Thu, 30 Nov 2006 16:34:39 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GptYA-0003IS-Rz for sip@ietf.org; Thu, 30 Nov 2006 16:34:39 -0500 Received: (qmail 15938 invoked by uid 0); 30 Nov 2006 21:35:31 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Nov 2006 21:35:31 -0000 Message-ID: <004e01c714c7$4c7a9d60$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Francois Audet" , References: <7374777208BDC7449D5620EF94232567AF83F6@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:34:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I still need to test this, but I suspect that the STUN response won't even arrive over TCP when the NAT has rebooted and uses a different source port for forwarding it. The server then cannot match it with an existing 5-tuple socket connection and will probably send a RST Regards, Jeroen Christer Holmberg (JO/LMF) wrote: > Hi, > > A question for clarification: > > The STUN response provides the UA with certain useful information > (XOR-ADDRESS etc), which the UA can use to see whether a NAT has > rebooted etc. I assume that information is not needed when using TCP? > > Regards, > > Christer > > > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: 30. marraskuuta 2006 19:45 >> To: sip@ietf.org >> Cc: rohan@ekabal.com >> Subject: RE: [Sip] Re: issue with oubound and the used >> transport protocol >> >> Didn't we agree way back NOT to use PING, CRLF, etc., and use >> STUN instead? >> >> Why is this debate being re-opened? >> >> Remember: I favored the non-STUN TCP approach. However, if we >> can't stick to a decision, we'll debate this forever. It >> already feels like it. >> >>> -----Original Message----- >>> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] >>> Sent: Thursday, November 30, 2006 08:02 >>> To: Christer Holmberg (JO/LMF); Rohan Mahy; >>> Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; rohan@ekabal.com >>> Subject: RE: [Sip] Re: issue with oubound and the used transport >>> protocol >>> >>> Having implemented STUN over TCP/TLS I can now say that it does add >>> significant complexity while providing little benefit over CRLF >>> >>> STUN allows one to detect NAT reboot, but a CRLF will also >> trigger a >>> connection reset in such a case. STUN breaks framing in >> case the other >>> side does not support it. It uses significantly more bandwidth than >>> CRLF. It requires a lot of text to describe. >>> >>> In summary, I support CRLF for TCP, and would suggest to do >> STUN only >>> for UDP (i.e. its original purpose). STUN for TCP is a bad idea >>> >>> Regards, >>> Jeroen >>> >>> PS Edge proxy choosing the mechanism: not a good idea >> either, better >>> to simply define 1 mechanism (STUN for UDP, CRLF for TCP) >>> >>> -----Oorspronkelijk bericht ----- >>> Van: "Christer Holmberg (JO/LMF)" >>> Aan: "Rohan Mahy" ; Erkki.Koivusalo@nokia.com >>> CC: sip@ietf.org; rohan@ekabal.com >>> Verzonden: 30-11-06 13:56 >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used transport >>> protocol >>> >>> >>> Hi, >>> >>> Why don't we let the edge proxy choose which keep-alive >> mechanism to >>> use? >>> >>> The outbound spec should now say (I haven't had time to >> check, but I >>> hope me and Rohan agreed to add it :) that the edge proxy >> can insert >>> the keepalive parameter in the Path header. >>> >>> So, we define a "CRLF" value for the parameter, and the >> edge proxy can >>> then use that value for TCP flows. >>> >>> Of course, if the UA is not mandated to implement all kind of >>> keep-alives, it will also have to be able to indicate to the edge >>> proxy which keep-alive mechanisms it support. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:44:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpth3-00035p-4W; Thu, 30 Nov 2006 16:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpth2-00035j-HF for sip@ietf.org; Thu, 30 Nov 2006 16:43:44 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpth1-0004m5-5J for sip@ietf.org; Thu, 30 Nov 2006 16:43:44 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAULhcR22255; Thu, 30 Nov 2006 16:43:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 15:43:37 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E37A093@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/A= From: "Francois Audet" To: "Kevin Johns" , "Fredrik Thulin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would think that UDP encapsulated IPsec would have it's own keep-alive. So they wouldn't need Outbound in the first place. Otherwise all the other applications would have a NAT problem. But even if they didn't then the CRLF thing would still work. > -----Original Message----- > From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 > Sent: Thursday, November 30, 2006 12:47 > To: Fredrik Thulin; Audet, Francois (SC100:3055) > Cc: sip@ietf.org; rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Not all architectures use TLS/TCP, some use UDP encapsulated IPsec. > Would a TCP session via UDP encapsulated IPsec be impacted by=20 > this? I do not think it would, but just wanted to double check... >=20 > Kevin >=20 > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: Thursday, November 30, 2006 11:21 AM > To: Francois Audet > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Francois Audet wrote: > > Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN=20 > > instead? > >=20 > > Why is this debate being re-opened? >=20 > Because it seems more and more (to me at least) that Outbound=20 > with UDP will just suck. >=20 > If Outbound UA's have to get their act together and implement=20 > TLS/TCP, then we can simplify Outbound even further by=20 > skipping the whole STUN keepalive thing, and go with CRLF=20 > over TLS/TCP. >=20 > I am very much in favor of cutting both UDP and STUN=20 > keepalives out of Outbound. I think that would lead to faster=20 > deployment, and also make the world a better place by=20 > eliminating some SIP over UDP. >=20 > /Fredrik >=20 > PS. By the way, when people say CRLF keepalives, do you mean=20 > CRLF sent only from the UA, or CRLF from UA to edge proxy=20 > followed by CRLF in the reverse direction too? >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptmG-0005Rc-Nr; Thu, 30 Nov 2006 16:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptmE-0005QK-Sj for sip@ietf.org; Thu, 30 Nov 2006 16:49:06 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gptm9-0005qn-DH for sip@ietf.org; Thu, 30 Nov 2006 16:49:06 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9DE6F1C1; Thu, 30 Nov 2006 22:48:58 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:48:58 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:48:57 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF8417@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E37A093@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oA== From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Kevin Johns" , "Fredrik Thulin" X-OriginalArrivalTime: 30 Nov 2006 21:48:58.0354 (UTC) FILETIME=[56F9C520:01C714C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I would think that UDP encapsulated IPsec would have it's own=20 >keep-alive. >So they wouldn't need Outbound in the first place. They may want to use outbound in order to support multiple simultanous registrations. So, if there would also be NATs, the question is what keep-alive they should use. Regards, Christer >=20 > But even if they didn't then the CRLF thing would still work. >=20 > > -----Original Message----- > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > Sent: Thursday, November 30, 2006 12:47 > > To: Fredrik Thulin; Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > > Not all architectures use TLS/TCP, some use UDP encapsulated IPsec. > > Would a TCP session via UDP encapsulated IPsec be impacted=20 > by this? I=20 > > do not think it would, but just wanted to double check... > >=20 > > Kevin > >=20 > > -----Original Message----- > > From: Fredrik Thulin [mailto:ft@it.su.se] > > Sent: Thursday, November 30, 2006 11:21 AM > > To: Francois Audet > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > > Francois Audet wrote: > > > Didn't we agree way back NOT to use PING, CRLF, etc., and=20 > use STUN=20 > > > instead? > > >=20 > > > Why is this debate being re-opened? > >=20 > > Because it seems more and more (to me at least) that=20 > Outbound with UDP=20 > > will just suck. > >=20 > > If Outbound UA's have to get their act together and=20 > implement TLS/TCP,=20 > > then we can simplify Outbound even further by skippiFrom sip-bounces@ietf.org Thu Nov 30 16:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptmG-0005Rc-Nr; Thu, 30 Nov 2006 16:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptmE-0005QK-Sj for sip@ietf.org; Thu, 30 Nov 2006 16:49:06 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gptm9-0005qn-DH for sip@ietf.org; Thu, 30 Nov 2006 16:49:06 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9DE6F1C1; Thu, 30 Nov 2006 22:48:58 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:48:58 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:48:57 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF8417@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E37A093@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oA== From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Kevin Johns" , "Fredrik Thulin" X-OriginalArrivalTime: 30 Nov 2006 21:48:58.0354 (UTC) FILETIME=[56F9C520:01C714C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I would think that UDP encapsulated IPsec would have it's own=20 >keep-alive. >So they wouldn't need Outbound in the first place. They may want to use outbound in order to support multiple simultanous registrations. So, if there would also be NATs, the question is what keep-alive they should use. Regards, Christer >=20 > But even if they didn't then the CRLF thing would still work. >=20 > > -----Original Message----- > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > Sent: Thursday, November 30, 2006 12:47 > > To: Fredrik Thulin; Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > > Not all architectures use TLS/TCP, some use UDP encapsulated IPsec. > > Would a TCP session via UDP encapsulated IPsec be impacted=20 > by this? I=20 > > do not think it would, but just wanted to double check... > >=20 > > Kevin > >=20 > > -----Original Message----- > > From: Fredrik Thulin [mailto:ft@it.su.se] > > Sent: Thursday, November 30, 2006 11:21 AM > > To: Francois Audet > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > > Francois Audet wrote: > > > Didn't we agree way back NOT to use PING, CRLF, etc., and=20 > use STUN=20 > > > instead? > > >=20 > > > Why is this debate being re-opened? > >=20 > > Because it seems more and more (to me at least) that=20 > Outbound with UDP=20 > > will just suck. > >=20 > > If Outbound UA's have to get their act together and=20 > implement TLS/TCP,=20 > > then we can simplify Outbound even further by skipping the=20 > whole STUN=20 > > keepalive thing, and go with CRLF over TLS/TCP. > >=20 > > I am very much in favor of cutting both UDP and STUN=20 > keepalives out of=20 > > Outbound. I think that would lead to faster deployment, and=20 > also make=20 > > the world a better place by eliminating some SIP over UDP. > >=20 > > /Fredrik > >=20 > > PS. By the way, when people say CRLF keepalives, do you=20 > mean CRLF sent=20 > > only from the UA, or CRLF from UA to edge proxy followed by CRLF in=20 > > the reverse direction too? > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptnR-0005yQ-FB; Thu, 30 Nov 2006 16:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptnP-0005xF-9K for sip@ietf.org; Thu, 30 Nov 2006 16:50:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GptnN-00060S-Mp for sip@ietf.org; Thu, 30 Nov 2006 16:50:19 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CAE88D4; Thu, 30 Nov 2006 22:50:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:50:16 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:50:15 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF841B@esealmw113.eemea.ericsson.se> In-Reply-To: <004e01c714c7$4c7a9d60$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUx0529Xamde77QOy8pxjVuPPpXQAAg+bg From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Francois Audet" , X-OriginalArrivalTime: 30 Nov 2006 21:50:16.0806 (UTC) FILETIME=[85BC9860:01C714C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I still need to test this, but I suspect that the STUN=20 >response won't even arrive over TCP when the NAT has rebooted=20 >and uses a different source port for forwarding it. The=20 >server then cannot mng the=20 > whole STUN=20 > > keepalive thing, and go with CRLF over TLS/TCP. > >=20 > > I am very much in favor of cutting both UDP and STUN=20 > keepalives out of=20 > > Outbound. I think that would lead to faster deployment, and=20 > also make=20 > > the world a better place by eliminating some SIP over UDP. > >=20 > > /Fredrik > >=20 > > PS. By the way, when people say CRLF keepalives, do you=20 > mean CRLF sent=20 > > only from the UA, or CRLF from UA to edge proxy followed by CRLF in=20 > > the reverse direction too? > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 16:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptnR-0005yQ-FB; Thu, 30 Nov 2006 16:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptnP-0005xF-9K for sip@ietf.org; Thu, 30 Nov 2006 16:50:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GptnN-00060S-Mp for sip@ietf.org; Thu, 30 Nov 2006 16:50:19 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CAE88D4; Thu, 30 Nov 2006 22:50:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:50:16 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 22:50:15 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF841B@esealmw113.eemea.ericsson.se> In-Reply-To: <004e01c714c7$4c7a9d60$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUx0529Xamde77QOy8pxjVuPPpXQAAg+bg From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Francois Audet" , X-OriginalArrivalTime: 30 Nov 2006 21:50:16.0806 (UTC) FILETIME=[85BC9860:01C714C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I still need to test this, but I suspect that the STUN=20 >response won't even arrive over TCP when the NAT has rebooted=20 >and uses a different source port for forwarding it. The=20 >server then cannot match it with an existing 5-tuple socket=20 >connection and will probably send a RST Maybe I missunderstood, but won't the STUN request create a new binding, in case the NAT has rebooted? Regards, Christer >=20 > Regards, > Jeroen >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > A question for clarification: > > > > The STUN response provides the UA with certain useful information=20 > > (XOR-ADDRESS etc), which the UA can use to see whether a NAT has=20 > > rebooted etc. I assume that information is not needed when=20 > using TCP? > > > > Regards, > > > > Christer > > > > > > > > > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> Sent: 30. marraskuuta 2006 19:45 > >> To: sip@ietf.org > >> Cc: rohan@ekabal.com > >> Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > >> protocol > >> > >> Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN=20 > >> instead? > >> > >> Why is this debate being re-opened? > >> > >> Remember: I favored the non-STUN TCP approach. However, if=20 > we can't=20 > >> stick to a decision, we'll debate this forever. It already=20 > feels like=20 > >> it. > >> > >>> -----Original Message----- > >>> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > >>> Sent: Thursday, November 30, 2006 08:02 > >>> To: Christer Holmberg (JO/LMF); Rohan Mahy;=20 > >>> Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; rohan@ekabal.com > >>> Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > >>> protocol > >>> > >>> Having implemented STUN over TCP/TLS I can now say that=20 > it does add=20 > >>> significant complexity while providing little benefit over CRLF > >>> > >>> STUN allows one to detect NAT reboot, but a CRLF will also > >> trigger a > >>> connection reset in such a case. STUN breaks framing in > >> case the other > >>> side does not support it. It uses significantly more=20 > bandwidth than=20 > >>> CRLF. It requires a lot of text to describe. > >>> > >>> In summary, I support CRLF for TCP, and would suggest to do > >> STUN only > >>> for UDP (i.e. its original purpose). STUN for TCP is a bad idea > >>> > >>> Regards, > >>> Jeroen > >>> > >>> PS Edge proxy choosing the mechanism: not a good idea > >> either, better > >>> to simply define 1 mechanism (STUN for UDP, CRLF for TCP) > >>> > >>> -----Oorspronkelijk bericht ----- > >>> Van: "Christer Holmberg (JO/LMF)" > >>> Aan: "Rohan Mahy" ;=20 > Erkki.Koivusalo@nokia.com > >>> CC: sip@ietf.org; rohan@ekabal.com > >>> Verzonden: 30-11-06 13:56 > >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used=20 > transport=20 > >>> protocol > >>> > >>> > >>> Hi, > >>> > >>> Why don't we let the edge proxy choose which keep-alive > >> mechanism to > >>> use? > >>> > >>> The outbound spec should now say (I haven't had time to > >> check, but I > >>> hope me and Rohan agreed to add it :) that the edge proxy > >> can insert > >>> the keepalive parameter in the Path header. > >>> > >>> So, we define a "CRLF" value for the parameter, and the > >> edge proxy can > >>> then use that value for TCP flows. > >>> > >>> Of course, if the UA is not mandated to implement all kind of=20 > >>> keep-alives, it will also have to be able to indicate to the edge=20 > >>> proxy which keep-alive mechanisms it support. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new devatch it with an existing 5-tuple socket=20 >connection and will probably send a RST Maybe I missunderstood, but won't the STUN request create a new binding, in case the NAT has rebooted? Regards, Christer >=20 > Regards, > Jeroen >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > A question for clarification: > > > > The STUN response provides the UA with certain useful information=20 > > (XOR-ADDRESS etc), which the UA can use to see whether a NAT has=20 > > rebooted etc. I assume that information is not needed when=20 > using TCP? > > > > Regards, > > > > Christer > > > > > > > > > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> Sent: 30. marraskuuta 2006 19:45 > >> To: sip@ietf.org > >> Cc: rohan@ekabal.com > >> Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > >> protocol > >> > >> Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN=20 > >> instead? > >> > >> Why is this debate being re-opened? > >> > >> Remember: I favored the non-STUN TCP approach. However, if=20 > we can't=20 > >> stick to a decision, we'll debate this forever. It already=20 > feels like=20 > >> it. > >> > >>> -----Original Message----- > >>> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > >>> Sent: Thursday, November 30, 2006 08:02 > >>> To: Christer Holmberg (JO/LMF); Rohan Mahy;=20 > >>> Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; rohan@ekabal.com > >>> Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > >>> protocol > >>> > >>> Having implemented STUN over TCP/TLS I can now say that=20 > it does add=20 > >>> significant complexity while providing little benefit over CRLF > >>> > >>> STUN allows one to detect NAT reboot, but a CRLF will also > >> trigger a > >>> connection reset in such a case. STUN breaks framing in > >> case the other > >>> side does not support it. It uses significantly more=20 > bandwidth than=20 > >>> CRLF. It requires a lot of text to describe. > >>> > >>> In summary, I support CRLF for TCP, and would suggest to do > >> STUN only > >>> for UDP (i.e. its original purpose). STUN for TCP is a bad idea > >>> > >>> Regards, > >>> Jeroen > >>> > >>> PS Edge proxy choosing the mechanism: not a good idea > >> either, better > >>> to simply define 1 mechanism (STUN for UDP, CRLF for TCP) > >>> > >>> -----Oorspronkelijk bericht ----- > >>> Van: "Christer Holmberg (JO/LMF)" > >>> Aan: "Rohan Mahy" ;=20 > Erkki.Koivusalo@nokia.com > >>> CC: sip@ietf.org; rohan@ekabal.com > >>> Verzonden: 30-11-06 13:56 > >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used=20 > transport=20 > >>> protocol > >>> > >>> > >>> Hi, > >>> > >>> Why don't we let the edge proxy choose which keep-alive > >> mechanism to > >>> use? > >>> > >>> The outbound spec should now say (I haven't had time to > >> check, but I > >>> hope me and Rohan agreed to add it :) that the edge proxy > >> can insert > >>> the keepalive parameter in the Path header. > >>> > >>> So, we define a "CRLF" value for the parameter, and the > >> edge proxy can > >>> then use that value for TCP flows. > >>> > >>> Of course, if the UA is not mandated to implement all kind of=20 > >>> keep-alives, it will also have to be able to indicate to the edge=20 > >>> proxy which keep-alive mechanisms it support. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip elopments on the application of sip > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 17:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpu4z-0004Zw-JV; Thu, 30 Nov 2006 17:08:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpu4y-0004XC-5z for sip@ietf.org; Thu, 30 Nov 2006 17:08:28 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpu4w-0000CM-SD for sip@ietf.org; Thu, 30 Nov 2006 17:08:28 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUM8ML23180; Thu, 30 Nov 2006 17:08:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 16:08:21 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E37A0FF@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF94232567AF8417@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lw From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" , "Kevin Johns" , "Fredrik Thulin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Right. My point was that the keep-alive didn't matter since any option will work, and you don't need one in the first place because the UDP/IPsec already has one. But it just occured to me... I'm thinking VPN, and you are probably thinking 3GPP. And I=20 don't know anything about how that works. :-) If that's the case, you can safely ignore my posting. > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, November 30, 2006 13:49 > To: Audet, Francois (SC100:3055); Kevin Johns; Fredrik Thulin > Cc: sip@ietf.org; rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > Hi,=20 >=20 > >I would think that UDP encapsulated IPsec would have it's own=20 > >keep-alive. > >So they wouldn't need Outbound in the first place. >=20 > They may want to use outbound in order to support multiple=20 > simultanous registrations. >=20 > So, if there would also be NATs, the question is what=20 > keep-alive they should use. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >=20 > > But even if they didn't then the CRLF thing would still work. > >=20 > > > -----Original Message----- > > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > > Sent: Thursday, November 30, 2006 12:47 > > > To: Fredrik Thulin; Audet, Francois (SC100:3055) > > > Cc: sip@ietf.org; rohan@ekabal.com > > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > > protocol > > >=20 > > > Not all architectures use TLS/TCP, some use UDP=20 > encapsulated IPsec. > > > Would a TCP session via UDP encapsulated IPsec be impacted > > by this? I > > > do not think it would, but just wanted to double check... > > >=20 > > > Kevin > > >=20 > > > -----Original Message----- > > > From: Fredrik Thulin [mailto:ft@it.su.se] > > > Sent: Thursday, November 30, 2006 11:21 AM > > > To: Francois Audet > > > Cc: sip@ietf.org; rohan@ekabal.com > > > Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > > > protocol > > >=20 > > > Francois Audet wrote: > > > > Didn't we agree way back NOT to use PING, CRLF, etc., and > > use STUN > > > > instead? > > > >=20 > > > > Why is this debate being re-opened? > > >=20 > > > Because it seems more and more (to me at least) that > > Outbound with UDP > > > will just suck. > > >=20 > > > If Outbound UA's have to get their act together and > > implement TLS/TCP, > > > then we can simplify Outbound even further by skipping the > > whole STUN > > > keepalive thing, and go with CRLF over TLS/TCP. > > >=20 > > > I am very much in favor of cutting both UDP and STUN > > keepalives out of > > > Outbound. I think that would lead to faster deployment, and > > also make > > > the world a better place by eliminating some SIP over UDP. > > >=20 > > > /Fredrik > > >=20 > > > PS. By the way, when people say CRLF keepalives, do you > > mean CRLF sent > > > only from the UA, or CRLF from UA to edge proxy followed=20 > by CRLF in=20 > > > the reverse direction too? > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 17:13:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpu9U-0007RX-1a; Thu, 30 Nov 2006 17:13:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpu9S-0007O1-EO for sip@ietf.org; Thu, 30 Nov 2006 17:13:06 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpu9R-0001Dt-1l for sip@ietf.org; Thu, 30 Nov 2006 17:13:06 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id kAUMCrOX007236; Thu, 30 Nov 2006 15:12:53 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 30 Nov 2006 15:12:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 30 Nov 2006 15:12:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwAAAi7sA= From: "Kevin Johns" To: "Francois Audet" , "Christer Holmberg (JO/LMF)" , "Fredrik Thulin" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Your right, I am thinking 3GPP which uses UDP encapsulated IPsec in tunnel mode and they do leverage the keep alives provided by UDP encapsulated IPsec if outbound is not used. If outbound is being used, STUN keepalives are utilized (at least at this time...) Kevin -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, November 30, 2006 3:08 PM To: Christer Holmberg (JO/LMF); Kevin Johns; Fredrik Thulin Cc: sip@ietf.org; rohan@ekabal.com Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Right. My point was that the keep-alive didn't matter since any option will work, and you don't need one in the first place because the UDP/IPsec already has one. But it just occured to me... I'm thinking VPN, and you are probably thinking 3GPP. And I don't know anything about how that works. :-) If that's the case, you can safely ignore my posting. > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, November 30, 2006 13:49 > To: Audet, Francois (SC100:3055); Kevin Johns; Fredrik Thulin > Cc: sip@ietf.org; rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > protocol >=20 >=20 > Hi, >=20 > >I would think that UDP encapsulated IPsec would have it's own=20 > >keep-alive. > >So they wouldn't need Outbound in the first place. >=20 > They may want to use outbound in order to support multiple simultanous > registrations. >=20 > So, if there would also be NATs, the question is what keep-alive they=20 > should use. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >=20 > > But even if they didn't then the CRLF thing would still work. > >=20 > > > -----Original Message----- > > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > > Sent: Thursday, November 30, 2006 12:47 > > > To: Fredrik Thulin; Audet, Francois (SC100:3055) > > > Cc: sip@ietf.org; rohan@ekabal.com > > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > > protocol > > >=20 > > > Not all architectures use TLS/TCP, some use UDP > encapsulated IPsec. > > > Would a TCP session via UDP encapsulated IPsec be impacted > > by this? I > > > do not think it would, but just wanted to double check... > > >=20 > > > Kevin > > >=20 > > > -----Original Message----- > > > From: Fredrik Thulin [mailto:ft@it.su.se] > > > Sent: Thursday, November 30, 2006 11:21 AM > > > To: Francois Audet > > > Cc: sip@ietf.org; rohan@ekabal.com > > > Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > > > protocol > > >=20 > > > Francois Audet wrote: > > > > Didn't we agree way back NOT to use PING, CRLF, etc., and > > use STUN > > > > instead? > > > >=20 > > > > Why is this debate being re-opened? > > >=20 > > > Because it seems more and more (to me at least) that > > Outbound with UDP > > > will just suck. > > >=20 > > > If Outbound UA's have to get their act together and > > implement TLS/TCP, > > > then we can simplify Outbound even further by skipping the > > whole STUN > > > keepalive thing, and go with CRLF over TLS/TCP. > > >=20 > > > I am very much in favor of cutting both UDP and STUN > > keepalives out of > > > Outbound. I think that would lead to faster deployment, and > > also make > > > the world a better place by eliminating some SIP over UDP. > > >=20 > > > /Fredrik > > >=20 > > > PS. By the way, when people say CRLF keepalives, do you > > mean CRLF sent > > > only from the UA, or CRLF from UA to edge proxy followed > by CRLF in > > > the reverse direction too? > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Nov 30 18:18:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpv8W-0007Mf-HN; Thu, 30 Nov 2006 18:16:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpv8V-0007MO-4t for sip@ietf.org; Thu, 30 Nov 2006 18:16:11 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpv8S-0001lO-K6 for sip@ietf.org; Thu, 30 Nov 2006 18:16:11 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1976752ugd for ; Thu, 30 Nov 2006 15:16:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RHjGvKLgo6vmpIb9TAnlcGyZf7zkvgQw+LtwUK7zrs9tN4OqnciDqZP7maR1/UWxPY9QGeV+NP9VOhuvmryIPOJ6HLpuGiW9XgrGtEzUw6w+YfRMZ9vporG9In54gUX4NnJgWyE1qHw86QX3Ago5VLi/chSofBq9bg5Nh81nEjs= Received: by 10.78.185.16 with SMTP id i16mr4148131huf.1164928566947; Thu, 30 Nov 2006 15:16:06 -0800 (PST) Received: by 10.78.120.15 with HTTP; Thu, 30 Nov 2006 15:16:06 -0800 (PST) Message-ID: <953beacc0611301516v611db212tc1b9f786293db283@mail.gmail.com> Date: Thu, 30 Nov 2006 15:16:06 -0800 From: "Rohan Mahy" To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <7374777208BDC7449D5620EF94232567AF841B@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c714c7$4c7a9d60$0601a8c0@BEMBUSTER> <7374777208BDC7449D5620EF94232567AF841B@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: sip@ietf.org, rohan@ekabal.com, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, A NAT won't create a new TCP binding unless it sees a SYN. If the NAT reboots, the client will detect that the connection has died, and won't be able to send any traffic (SIP or STUN) until it opens a new connection explicitly. An XOR-MAPPED-ADDRESS attribute over TCP is completely useless. thanks, -rohan On 11/30/06, Christer Holmberg (JO/LMF) wrote: > > Hi, > > >I still need to test this, but I suspect that the STUN > >response won't even arrive over TCP when the NAT has rebooted > >and uses a different source port for forwarding it. The > >server then cannot match it with an existing 5-tuple socket > >connection and will probably send a RST > > Maybe I missunderstood, but won't the STUN request create a new binding, > in case the NAT has rebooted? > > Regards, > > Christer > > > > > > > > Regards, > > Jeroen > > > > Christer Holmberg (JO/LMF) wrote: > > > Hi, > > > > > > A question for clarification: > > > > > > The STUN response provides the UA with certain useful information > > > (XOR-ADDRESS etc), which the UA can use to see whether a NAT has > > > rebooted etc. I assume that information is not needed when > > using TCP? > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Francois Audet [mailto:audet@nortel.com] > > >> Sent: 30. marraskuuta 2006 19:45 > > >> To: sip@ietf.org > > >> Cc: rohan@ekabal.com > > >> Subject: RE: [Sip] Re: issue with oubound and the used transport > > >> protocol > > >> > > >> Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN > > >> instead? > > >> > > >> Why is this debate being re-opened? > > >> > > >> Remember: I favored the non-STUN TCP approach. However, if > > we can't > > >> stick to a decision, we'll debate this forever. It already > > feels like > > >> it. > > >> > > >>> -----Original Message----- > > >>> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > > >>> Sent: Thursday, November 30, 2006 08:02 > > >>> To: Christer Holmberg (JO/LMF); Rohan Mahy; > > >>> Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; rohan@ekabal.com > > >>> Subject: RE: [Sip] Re: issue with oubound and the used transport > > >>> protocol > > >>> > > >>> Having implemented STUN over TCP/TLS I can now say that > > it does add > > >>> significant complexity while providing little benefit over CRLF > > >>> > > >>> STUN allows one to detect NAT reboot, but a CRLF will also > > >> trigger a > > >>> connection reset in such a case. STUN breaks framing in > > >> case the other > > >>> side does not support it. It uses significantly more > > bandwidth than > > >>> CRLF. It requires a lot of text to describe. > > >>> > > >>> In summary, I support CRLF for TCP, and would suggest to do > > >> STUN only > > >>> for UDP (i.e. its original purpose). STUN for TCP is a bad idea > > >>> > > >>> Regards, > > >>> Jeroen > > >>> > > >>> PS Edge proxy choosing the mechanism: not a good idea > > >> either, better > > >>> to simply define 1 mechanism (STUN for UDP, CRLF for TCP) > > >>> > > >>> -----Oorspronkelijk bericht ----- > > >>> Van: "Christer Holmberg (JO/LMF)" > > >>> Aan: "Rohan Mahy" ; > > Erkki.Koivusalo@nokia.com > > >>> CC: sip@ietf.org; rohan@ekabal.com > > >>> Verzonden: 30-11-06 13:56 > > >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used > > transport > > >>> protocol > > >>> > > >>> > > >>> Hi, > > >>> > > >>> Why don't we let the edge proxy choose which keep-alive > > >> mechanism to > > >>> use? > > >>> > > >>> The outbound spec should now say (I haven't had time to > > >> check, but I > > >>> hope me and Rohan agreed to add it :) that the edge proxy > > >> can insert > > >>> the keepalive parameter in the Path header. > > >>> > > >>> So, we define a "CRLF" value for the parameter, and the > > >> edge proxy can > > >>> then use that value for TCP flows. > > >>> > > >>> Of course, if the UA is not mandated to implement all kind of > > >>> keep-alives, it will also have to be able to indicate to the edge > > >>> proxy which keep-alive mechanisms it support. > > >>> > > >>> Regards, > > >>> > > >>> Christer > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP 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